別のクラスをテストするためにビジネスロジッククラスを使用してデータを構築することについて、オフィスの誰かと会話するだけです。
基本的に、彼はクラスAを持っており、パラメーターとして複合型を取り、結果として異なる複合型のコレクションを生成します。彼はすでにこのクラスの周りにテストを書いています。次に、彼は別のクラス（クラスB）のテストに移ります。このクラスは、クラスAの結果を取得し、その上でいくつかのロジックを実行します。
彼は、「クラスAを使用して、クラスBをテストするシナリオを構築する必要があるか」という質問をしました。
クラスAにはテストがあるので、最初は「はい」と答えました。しかし、クラスAにまだ発見されていないバグがある場合はどうなるかをよく理解しました。したがって、このシナリオに対処するためのより良い方法があるはずです。
誰かがこれについて何か考えを持っていますか？他のテストを書く時間を節約するために既存のロジックを使用しても大丈夫ですか？
よろしく、
ジェームズ
そのスタンスは異なる場合があります。一般に、コードがテストされ、それが機能すると想定している場合は、自由に使用できます。これは、すでにテスト済みのメソッドを使用して他のメソッド（単一のクラス/ユニット内）のテストに役立てる場合に特に当てはまります。ただし、これは単一のユニット内で発生するため、ケースとは少し異なります。
さて、2つの別々のクラスを扱うときは、そのようなアプローチを避けるべきだと思います。純粋に、これら2つのクラスが明白な方法で関連していないか、それらのコンテキスト/使用範囲が大きく異なる可能性があるという理由で。のように、誰かがクラスBが存在することさえ知らずにクラスAを変更する可能性があります。Bコードに変更が加えられていないのに、クラスBテストが突然中断します。これは不必要な混乱をもたらし、通常は自分自身を見つけたくない状況です。
代わりに、テスト済みのクラスBファイル内にヘルパーメソッドを作成することをお勧めします。スタブ/フェイクとAutoFixtureのようなツールを使用すると、クラスAで使用される生成ロジックを簡単に再現でき、クラスBのテストに独自の「コピー」を含めることができます。
クラスBをテストするには、クラスAから返された結果をテストのどこかに複製する必要があります。クラスAが人物のリストを返す場合、テストList<Person>で使用する偽物を返すヘルパー関数がテストに含まれます。クラスBのみをテストしているため、テストでクラスAを使用しないでください。
NUnitは、テスト用のデータを提供するための組み込み機能を提供します 。http ：//www.nunit.org/index.php？p = testCaseSource＆r=2.5を参照してください。
または、テストで使用するデータ（単純なオブジェクト、コレクションなど）を返すメソッドを使用してDataFactoryクラスを作成することもできます。