テストデータベースが存在するTDD

例外的な状況を除いて、単体テストでデータベースにヒットすることは一般に悪いことです。

私はEFを使用してMVCプロジェクトにTDDアプローチをとっています。私の最初のテストは：

void DatabaseShouldExist() { ... }

私は知っていると思います...これは例外的な状況ですか？

EFがDBを生成したことを確認し、次のテストで正しいシードデータが含まれているかどうかを確認します。

これをテストするにはどうしたらいいですか？

テストする必要がありますか？

をテストするために、インメモリデータベースを使用するようにしてくださいMockingフレームワーク。 NS代理人。 – Karolis

私は同意しません。 DAOをテストしている場合、データベースにヒットする以外のことは意味をなさない。これが完了すると、DAOに依存するクラスはモックに依存することができます。私は、データベースが存在するかどうかを確認するためのテストを書いていません。私は先験的にそれを仮定する。 – duffymo

統合テスト*を行うのは悪いことではありません。唯一のことは、 "ユニット"テストと同じではありませんが、非常に便利です。さらに、私は@duffymoに完全に同意します。データベースが作成されていない場合は、気づくでしょう。心配しないでください。 –

DBが存在するかどうかを判断するために、動作をテストする必要があります。コメントに示唆されているように、ビジネスロジックから始めます。 TDDは小さな始まり、反復され、TDDを使用する場合は、（Appの動画を保存するために）DBのロジックテスト1

単純化した例に

Test 1 - shouldAddAMoveToList() 
Test 2 - shouldBeAbleToRetrieveAMovieFromList() 
Test 3 - shouldPersistAMovieBeweenSessions() // Could Be DB here

を潜る最初のシンプルなものを選ぶことはありません。 DB部分は少し後で演奏されるべきです。

個人的には、単体テストでDBとのテストを避け、統合テスト用に保存します。 DAOパターンはメモリに残っているか、単純に単体テストでDB側を模倣しているので、これに適しています。

ユニットテストは、テストを遅くすることができますデータベースを導入し、FIRST principleを遵守しようとすると、彼らは（DBを毎回クリアしない限り）独立していることを防止すべきである - 少なくとも、非常にするユニットは

2016-05-17 20:41:44 MikeJ

申し訳ありませんDAOパターンは何ですか？ –

データアクセスオブジェクト - このリンクを参照してください。 http://www.tutorialspoint.com/design_pattern/data_access_object_pattern.htm – MikeJ

マイクに感謝します。私はデータアクセスのためにEntity Frameworkを使用しています。それはPOCOを使用するので、その意味で嘲笑リポジトリは合理的です。 –

答えて