VisualStudio統合テスト環境を使用していくつかのテストを作成しました。これらのテストは、BLLメソッド（UIレイヤーが認識して対話する必要があるメソッドのみ）を呼び出すことにより、Webアプリケーションが行うことをシミュレートします...
したがって、それらの動作が正しい場合（テストに合格した場合）、多くの文献で推奨されているように、DAL /ストアドプロシージャなどの下位層のテストを作成する必要があるのはなぜですか？
2 に答える
2
エンドツーエンドのテストは適切であり、アプリケーションが特定のシナリオで機能していることを確認します。
Misko Heveryは、テストの分類について優れたブログ投稿を行い、単体テスト、統合テスト、およびエンドツーエンドテストを分割しています。
単体テスト 単体テストは、その関数メソッドのロジックが正しいことを実行していること、およびエラー処理が正しく実行されていることを確認します。これらのテストは、理想的には秒ではなくミリ秒で実行する必要があります。関数がDALなどの何かと対話する必要がある場合は、実際の対話の実行に長い時間がかかるため、DALのそのインターフェイスをモックする必要があります。これらは最高の投資収益率を提供します
統合テスト このレベルのテストでは、ビジネスロジックレイヤー間の相互作用が、実行すべきことを正確に実行することを確認します。これは、単体テストがDALなどのインターフェースと対話し、「配線」が正しいことを確認する場所です。これらはいくつかあるはずですが、ビルド時間に影響を与えるので多すぎないようにしてください
エンドツーエンドのテスト これらは、UIからDALに至るまですべてが一緒にハングアップしていることを確認するので優れています。これらは、より多くの「配線」をテストし、ユーザーが実行できることがアプリケーションを強制終了しないことを確認します。これらには、 FitNesseやSeleniumなどのWebテストに合格していることも含まれます。
ユニットテストは、投資収益率が最も高く、他の領域よりもはるかにコストのかかるバグを検出しますが、多くを適切に組み合わせるのは良いことです。
于 2009-07-17T08:55:03.767 に答える
0
NUnitのバックグラウンドから話す
SP/データアクセスのテストはそれほど簡単ではありません。テストを実行するたびに「クリーンな」データベースがあり、意図した結果が得られることを保証するために、開始時に期待されるデータが含まれていることを確認する必要があります。したがって、毎回クリーンバックアップからデータベースを復元するか、テストを開始する前に、テストで必要なデータを使用してデータベースをセットアップする必要があります。
ユニットテストは、理想的には可能な限り高速に実行する必要があります。これは、データベースの相互作用のコストのかかるプロセスを削除するために、ユニットテスト時にDALがしばしば嘲笑される理由の1つです。注意しなければならないのは、SP / DALの「単体テスト」を作成すると、テストの実行時間への影響が急増する可能性があり、私の経験では、時間がかかりすぎるためにテストを実行できなくなる可能性があります。特に継続的インテグレーション環境/ビルド環境では、テストの実行に時間がかかるほど、ビルドの準備にかかる時間が長くなります。
私の個人的な意見では、ユニットテストでモックと実際のdbアクセスを組み合わせて使用するのが好きです。これは、コードがdbとの間で期待どおりに実行され、SPのようなばかげた間違いをキャッチできることを知りたいからです。欠落/エラー（単体/統合/機能テスト間の境界）。しかし、それほど重要ではない場合は、モックを使用します。
于 2009-07-17T08:42:04.510 に答える