4

私はTDDの大ファンであり、本番コードを作成する前にテストを作成して、作成しているコードが正しく動作することを確認するよう常に努めています。ただし、場合によっては、特定の種類のメソッドに対して大量のテストを作成することが賢明かどうかという疑問がいくつかあります。これは、マッパークラスを作成するときに最も頻繁に発生するようです。

public class FooBarMapper
{
    public Foo MapToFoo(Bar bar)
    {
        return new Foo
        {
            Id = bar.Id,
            Name = bar.Name,
            FooYuk = bar.Beverage,
            /* ... */
        };
    }
}

たとえば、上記にマップするプロパティが約12個あるとします。TDD環境では、マッピングを作成する前に、おそらくテストを作成します。のようなものMapToFooMapsBeverageToFooYuk()。テストが失敗し、合格するためのコードを書くことになりました。マップするプロパティごとにこれを繰り返します。問題は、これはテストファースト開発をやりすぎているのかということです。私は個人的にはそうは思いません。コードが何をするのかを正確に教えてくれる完全なテストスイートが欲しいのですが、コミュニティの考えを聞きたいのです。

4

4 に答える 4

3

TDDおよびすべてのTDDの堅固な擁護者であるUncleBobMartinでさえ、すべての些細なプロパティ（メンバー変数を取得および設定するプロパティとして定義されている些細なプロパティ）に対して単体テストを作成する必要はないと言います。

副作用のあるプロパティを作成したことがある場合（これは間違いですが）、単体テストを追加できます。DuffyMoが指摘しているように、プロパティが機能テストの対象である場合、単体テストで定義する機能の仕様は簡単なget / set以外にないため、単体テストは必要ありません。

于 2010-01-16T18:15:52.583 に答える
0

たぶんこれがFitNesseが生まれた理由です。

于 2010-01-16T17:57:22.530 に答える
0

この例では、すべての些細なプロパティを一度にテストする単一のテストを作成します。これは物事を行うための標準的な方法ではありませんが、最終的には、個々の些細なプロパティのテストが、すべてのプロパティの単一のテストにリファクタリングされる可能性があります。プロパティは些細なものなので、終了したテストから始めることをお勧めします。

于 2010-01-16T18:42:04.833 に答える
0

最初の3つのプロパティをマッピングした後、重複を確認し、プロパティを反復処理してリフレクションを使用して割り当てることで置き換えます。これには、いくつかのテストのみが必要です。0プロパティ、1プロパティ、5プロパティ、ターゲットオブジェクトに期待されるプロパティがない、ソースオブジェクトに期待されるプロパティがない。これで、この一般的なマッピングエンジンをすべてのアプリケーションで他の場所で再利用できるようになり、使用するたびにチェックする必要がなくなりました。

于 2010-01-20T08:14:01.007 に答える