6

と呼ばれる古いユニットにいくつかの小さな関数がありUtils.pasます。

今、それらのいくつかをリファクタリングしたいのですが、前にテストを書く方が良いと思います。DUnitでは、クラスなしでは不可能だと思います。

では、リファクタリングの前にそれらをテストするにはどうすればよいですか？

編集：

テストケースウィザードを使用してDelphiにテストケースを追加しようとしていたため、不可能だと思いました。次の図を参照してください。クラスとメソッドがないため、作成できません。

ここに画像の説明を入力してください

4

3 に答える 3

8

AFAICT、DUnitは、テスト対象のコードがクラスメソッドとして存在する必要はありません。テストケース自体のみがクラスである必要があります。

編集：ウィザードはただの便利です。使用する必要はありません。

于 2011-06-14T11:23:30.873 に答える
7

ウィザードを使用してスタンドアロン関数をテストすることはできませんが、DUnitを使用してスタンドアロン関数をテストすることは問題ありません。

例

  //***** A Standalone function te be tested in a unit far, far away
  function Add(v1, v2: Integer): Integer;
  ...

  //***** A testclass to contain the testmethods calling our 
  //      standalone function     
  TTestAdd = class(TTestcase)
  published
    procedure AddingComplement_ShouldEqualZero;
    procedure AddingNegativeNumbers_ShouldBeLessThanZero
    ...
  end;

  implementation

  procedure TTestAdd.AddingComplement_ShouldEqualZero;
  begin
    // Setup, Execute & Verify
    CheckEquals(0, Utils.Add(-1, 1), 'Complement doesn''t add to zero');
  end;

  procedure TTestAdd.AddingNegativeNumbers_ShouldBeLessThanZero
  begin
    // Setup, Execute & Verify
    CheckEquals(-3, Utils.Add(-1, -2), 'Add doesn''t add');
  end;
于 2011-06-14T11:26:05.283 に答える
1

実際のコードを維持する必要があります。実際のコードには、十分に文書化されていない仮定があります。実際のコードは、それらの仮定を忘れたり、知らなかったりする人々によって変更されます。テストを信頼し、コードを信頼しないでください。

実際のTDDを使用すると、実装前にオブジェクトとそのメソッドを作成できます。とにかくテストケースを書く前に、明確なモデルが必要です。

したがって、オブジェクトを生成し、メソッド、パラメーターなどを追加します。おそらくUML2を使用するのが最善であり、それらのテストケースを作成してから、オブジェクトを実装します。その後、プロファイラーを実行して、コードが実際にどれほど恐ろしいかを調べ、リファクタリングします。

一般的な解決策として、ほとんどの場合、オブジェクトをインスタンス化および初期化するファクトリオブジェクトを作成するのが最善です。コア機能に近づくほど、これが重要になります。

予想される障害と例外のテストを作成します。チェックを使用して確認してください。

最後に、各テストを記述し、失敗するのを確認してから、コードを記述して成功させます。

于 2012-04-25T16:30:07.953 に答える