5

各単体テストはどれくらい検査する必要がありますか? たとえば、私はこのテストを持っています

[TestMethod]
public void IndexReturnsAView()
{
    IActivityRepository repository = GetPopulatedRepository();
    ActivityController activityController = GetActivityController(repository);
    ActionResult result = activityController.Index();
    Assert.IsInstanceOfType(result, typeof(ViewResult));
}

そしてまた

[TestMethod]
public void IndexReturnsAViewWithAListOfActivitiesInModelData()
{
    IActivityRepository repository = GetPopulatedRepository();
    ActivityController activityController = GetActivityController(repository);
    ViewResult result = activityController.Index() as ViewResult;
    Assert.IsInstanceOfType(result.ViewData.Model, typeof(List<Activity>));
}

明らかに、最初のテストが失敗した場合、2 番目のテストも失敗するので、これら 2 つを 2 つのアサートで 1 つのテストに結合する必要がありますか? 私の感覚では、テストがより細かく、各テストのチェックが少ないほど、失敗の原因を見つけるのが速くなると思います。ただし、すべてのテストを実行するのに時間がかかる可能性がある、非常に小さなテストを多数持つことにはオーバーヘッドがあります。

4

5 に答える 5

12

できるだけ分解することをお勧めします。

これには多くの理由がありますが、私見で最も重要な理由は次のとおりです。

  • テストの1つが失敗した場合、問題の原因を可能な限り迅速かつ安全に正確に特定できるようにする必要があります。これを達成するための最良の方法は、各テスト方法で1つのことだけをテストすることです。

  • 各テストは、白紙の状態から開始する必要があります。リポジトリを一度作成してから2つ以上のテストで使用する場合、それらのテストの順序に暗黙的に依存します。Test1がリポジトリにアイテムを追加したが、削除するのを忘れたとします。Test2の動作が異なり、テストが失敗する可能性があります。これに対する唯一の例外は、不変のデータです。

あなたの速度の懸念に関しては、私はそれについて心配しません。このような純粋なコード処理の場合、.NETは非常に高速であり、違いを見分けることはできません。コードの処理から抜け出し、データベースなどに入るとすぐにパフォーマンスの問題が発生しますが、それを実行するとすぐに、上記のすべての「クリーンスレート」の問題が発生するため、それと一緒に暮らす必要があります（または、できるだけ多くのデータを不変にする）。

テストで頑張ってください。

于 2009-06-07T21:12:02.500 に答える
3

きめが細かいほど良い。テストケースでアサートが失敗すると、テストケースはそれ以上実行されません。ケースの後半では、他のエラーが明らかになる可能性があります。

テストケース間で共有コードがある場合は、セットアップ/ティアダウン関数を使用して、あまり繰り返さずにそれを処理します。多くの場合、時間コストはごくわずかです。セットアップ/ティアダウンに時間がかかりすぎる場合は、単体テストではなく、より高いレベルの自動テストを実行している可能性があります。ユニットテストには、理想的には、ファイルシステム、ネットワーク、データベースなどの依存関係があってはなりません。

于 2009-06-07T21:12:35.570 に答える
2

「標準的な」答えは、コードにバグがある場合、1 つのテストを中断する必要があるが、このテストが失敗したときに他の失敗を非表示にしない (他のテストの実行を停止しない) という点に到達する必要があると思います。 . 各テストは 1 つのことをテストし、2 つのテストは同じことをテストしません。これは理想であり、常に実現できるわけではありません。ガイダンスと呼んでください。

そうは言っても、それはまさに芸術です。最初はパフォーマンスの問題を脇に置き、保守性に重点を置きます。2 行半から 3 行の重複があります。設計が変わると、それを維持するのが難しくなります。この場合、重複自体はクラス内のファイルのセットアップ メソッドで解決できますが、主に懸念されるのは保守性です。

テストは、維持しやすく、理解しやすく、コードが何をしているかを他の人 (または時間の経過後にあなた) が理解し、テストを維持できるように十分に小さくする必要があります。

于 2009-06-07T22:08:17.563 に答える
0

単体テストでは、機能設計の観点から、技術設計に記述されている内容を正確にテストする必要があります。

于 2009-06-07T21:15:36.360 に答える
0

テストがどれだけテストされるかについてのアプローチは、間違いなく、事前に決定し、それに固執する必要があるものです. チームやプロジェクトが異なれば、コーディング、パフォーマンス、トラブルシューティング、テスト インフラストラクチャなどに対する優先順位も異なるため、すべての人が同じアプローチを一律に従うべきだとは思いません。

  1. 掘り下げる深さが事前にわかっているため、問題をより迅速に特定できます。
  2. テストの作成に費やす時間を短縮します。
  3. テストを実装する際に、同じ一連のテスト ヘルパー クラスを使用します。
  4. 速すぎず、遅すぎず、十分な速さでテストを実行してください。
  5. テストの整理 (スイート、パッケージなど)

パフォーマンスがより重要であると判断した場合は、より多くの検証/アサーションを使用してより厚いテストを実装します。トラブルシューティングが最も重要であると判断した場合は、必要に応じてテストを分離してください。厚くてよく構造化されたテストに欠陥がある理由がわかりません。このようなテストは、より多くのシンナー テストと同じように実行されます。

もちろん、すべてのテストは特定の機能/機能に焦点を当てる必要がありますが、これはこのスレッドのトピックではありません。

于 2009-07-20T16:16:36.153 に答える