大規模なコレクションを使用した単体テスト - このような状況をどのように最善に処理しますか?

非常に大きなコレクションの事前初期化を必要とするいくつかのシナリオをユニットテストする必要がある状況がありますが、ユニットテストが機能するためには事前に初期化されたデータをハードコードする必要があります。

このようなことの典型的な慣行はありますか?それとも、大部分のあなたは、単体テストの中で厄介な変数を作り、それを使うだけですか?他の開発者がこのような状況にどのように取り組んでいるかについて、私は非常に不思議でした。

1

1 答え

このデータがさまざまなテストで使用されている場合は、データを保持するために静的コンテナを使用します(データは変更されないものとします)。テストでは、必要なときにこれを参照することができます。

データがフィクスチャに固有のものであれば、スコープを狭くするためにフィクスチャの一部になっただけです。

データの他の部分については、模擬/スタブ技術を使用してテストデータを公開することができます。私たちのデータの多くは、DALインターフェイス、静的なものであっても、私たちが使用する通常のインターフェイスメソッドを通じて静的データを提供するインターフェイスのテスト実装をスタブしています。私たちのテストの多くは、このスタブを使って構築されています。

これをSpecFlowと組み合わせて使用​​します。 DALスタブに入力される Background:テーブルを定義することができます。このDALは、DALインターフェイスを使用してデータと通信するときに挿入されます。大量の静的データの場合は、DALスタブが要求に応じて取得できる領域にハードコードまたはコードジェネレートを行います。

もちろん、これは必ずしもあなたがそれをやるべきではありません。これは私がそれがどのように処理されたか見てきただけです。


ただし、事前初期化されたデータはユニットテストのためにハードコードする必要があります   

私の意見では、出力を証明するためにセットデータを必要とするテストには何も問題はありません。外部のものが分離され、問題のメソッドだけをテストする真の単体テストが混在していますが、SpecFlowではより広い範囲でテストする「ユースケース」テストがあります。しかし、これには依然として定義された入力が必要です。


制御下に置くべき重要なことの1つは、単体テストが可能な限り分離されていることです。フィクスチャを使用すると、スコープを小さなテストコレクションに拡張することができますが、多くのテストで使用されている潜在的に変更可能なバッキングデータがたくさんある場合は、一歩前に戻る必要があります。

私たちは最近、不変ではない設定アクションの静的リストを持っていました。変更を加えると、変更後のテストが影響を受けます。私たちはこれを確認し整理しましたが、それは自明ではありませんでした。

2
追加された