testing - Fitnesse-テストはデータベースと通信する必要がありますか？

Question

機能テストにFitnessを使用しようとしています。依存関係をモックする必要がありますか、それともデータベースに対してテストする必要がありますか？

どちらのアプローチの長所/短所は何ですか？

DBに対するテストの全体的な問題は、大きな依存関係にあるデータを設定することです。私たちがモックするなら、それは本当の機能テストですか？

ありがとう

Answer 1

「InMemory」と「Database」の2つのモードでfitnesseで実行されるエンドツーエンドの機能テストのフルセットがあります。テストを実行する構成に応じて、テストで使用するリポジトリが決まります。これにはいくつかの利点があります。

1）開発者がデータベースに多くの機能を組み込むことを防ぎ、コードを維持します。

2）「インメモリ」の場合、フィットネステストは非常に高速に実行されます。テストが非常に速く失敗することを可能にする...したがって、開発と敏捷性をスピードアップします。それらがdbモードで実行される場合、それらは少し時間がかかります。

Answer 2

FitNesseで実行できる（少なくとも）2種類のテストがあります。

• ドメインロジックまたは動作を指定することを目的としたテスト（または例）。これらは通常、テストの目的にとって重要ではないため、データベースアクセスでは使用しない傾向があります。

• 回帰テストまたはスモークテストとして使用されるエンドツーエンド（またはほぼエンドツーエンド）のテスト。これらには、明らかにデータベース機能が含まれています。

DBを含めることの利点は、テストが実際の本番システムをより代表することです。欠点は、データベースの状態をセットアップおよび管理するための追加コストです。DBのセットアップと検証を支援するために設計された一連のフィクスチャであるDbFitを見てください。

Answer 3

NUnitのDBを含む統合テストを分離したいと思います。統合の問題が原因で、機能テストが失敗することはありません。DBよりも単純なシングルトンを介してオブジェクトの状態を運ぶ方が快適であることがわかりました。

Answer 4

データベースに対してテストする必要があると思います。なぜなら、fitnesseで機能テストを行っているので、モックを使用するべきではないからです。データベースでこれを使用して、DBに膨大なデータがあるため、実際のデータベース機能が正常に機能しているかどうかを確認します。

Answer 5

私はDB関連のもののために別のテストスイートを作成することに取り組んできました。これにより、他の機能テストに入るときに自信が持てるようになります。ビジネスルール、ストアドプロシージャ、いくつかの基本的で重要なテーブルなどを検証して、それらが想定されている場所にあることを確認し、正しい結果をレンダリングすることができます。それが期待どおりである場合、フロントエンドに表示されるのは、機能テストを実行するための堅固な環境である必要があります。