0

新しい MVC4 アプリの一連の単体テストをレトロコーディングしようとしています。EF データ プロジェクトのほとんどすべてのコードは、VS2012 EF リバース エンジニアリング ツールによって生成されたコードから直接コピーされているため、自動生成できない限り、アプリケーションのこの部分の単体テストをスキップすることにしました。ここにはビジネス ロジックはありません。まず、ビジネス側でより良い QA を確保することに力を注ぎたいと思います。しかし、最初の TDD について、次に一般的な単体テストについて知りたいと思います。

データベースをまだモックする必要がない、またはモックしたくないと仮定しましょう。以前は、テスト用の DB コピーに対して単体テストを行っていましたが、より従来型のホーム ロール ORM を使用していました。

では、駆動された DbContext をインスタンス化するテストから始めて、そのテストに合格するまで DbContext を派生させますか。次に、エンティティのインスタンス化をテストし、エンティティを作成して、それらのエンティティの DbSet をテストします。このテストには、テーブルが作成されているかどうかのチェックも含まれます。血まみれの骨の折れる作業ではないにしても、すべてはまだ順調ですが、すべてのエンティティに対して流暢なマッピングクラスをテストするヒントさえ考え始めるとすぐに、私の頭は爆発します. 今何？

4

1 に答える 1

2

データベースに対するテストは単体テストではありません。統合テストであり、統合テストは通常​​、単体テストの粒度に準拠していません。なぜユニットテストではないのですか？ユニットテストは単一の自己完結型ユニットをテストするため、すべての外部依存関係は偽造されます。テストがユニットコードとデータベースの両方にまたがる場合、依存関係もテストします=統合テストです。

EFに依存するすべてのコードは、統合テストでテストする必要があります。Microsoftのコードを単体テストするのは意味がありません。たとえば、マッピングに関する質問です。マッピングの正しい単体テストは次のようになります。

  • 準備：エンティティマッピング構成を使用してコンパイル済みモデルを準備します
  • 実行：コンパイルされたモデルからDbContextを作成し、コンテキストからメタデータワークスペースを取得します
  • 検証：メタデータコンテキストにマップされたエンティティが含まれていることを表明します

これで、そのエンティティにマップするすべてのプロパティに対して同様のテストを繰り返すことができます。

それは明らかにすでに機能するはずのフレームワークコードです-これらのテストはフレームワークを開発している人々によって行われるべきです。

あなたの場合、ローカルデータベースに対して統合テストを行うだけで、エンティティのロード、保存、更新、削除を試み、これらの操作に対する期待を表明します。マッピングのいずれかが間違っている場合、これらのテストの少なくとも1つは失敗します。

于 2012-07-02T13:41:49.677 に答える