7

依存性注入を扱う初心者を考えてみましょう。NerdDinnerで2つの関連するクラスを分析しています。

アプリケーションからのDinnerRepository： レポ画像

テストからのFakeDinnerRepository： 偽の画像

IDinnerRepositoryここでの重要なアイデアは、を実装し、さまざまな実装とプライベートメンバーを提供することであるため、これらはさまざまなロジックを実装します。これはもちろん必要です。

テストはコントローラー用であることは理解していますが、データアクセスロジックには2つの異なる実装があるのではないかと心配しています。あらゆる種類のORM、ADO.NET、SubSonic、または任意の種類のデータアクセスを使用するプロジェクトを検討してください。はい、実際のリポジトリと一致するように偽のリポジトリを設定できます。

私が心配しているのは、時間の経過とともに、実際のリポジトリの実装の詳細が変わることです。おそらく、タイプミス、またはクエリ内の他の重要な実装の詳細の変更です。これにより、偽のリポジトリと実際のリポジトリの間でモデルのロジックが一致しない可能性があります。心配なのは、実際のリポジトリとテストリポジトリの実装が同期しなくなることです。

質問：

  • この場合、モデルをどのようにテストしますか？
  • モデルをテストするのは適切ですか？
  • テストがビジネスロジックの実装に追いつくようにするのは規律の問題ですか？
4

2 に答える 2

4

これはおそらくあなたの質問に対する完全な答えではありませんが、私はそこへの道のりの一部を手に入れようとします.

インターフェース (この場合は IDinnerRepository) は、コントラクトと見なす必要があります。つまり、どの実装もこの契約を履行する必要があります。メソッドが FindAllDinners() の場合、基本的にそれが実行されるべきことです。単体テストに使用される偽のリポジトリは、通常、本物よりもはるかに単純である可能性があります (たとえば、辞書を使用)。したがって、実際の実装に遅れずについていくことは、実際には問題と見なされるべきではなく、要件と見なされるべきです。

そもそも偽のリポジトリが存在する理由はテストです。基本的に、テストできるものはすべてテストする必要があります。そして、データベースを方程式から除外することが、インメモリ フェイク リポジトリのポイントです。データアクセスはテストのポイントではないので、置き換えます。偽のリポジトリは、セットアップと使用がはるかに高速であり、テスト対象のコードが合格するために必要な状態にリポジトリがあることを簡単に確認できます。

したがって、ユニット テストで偽のリポジトリのコピーをモデルに渡し、モデル コードで何が起こっても偽のリポジトリに反映されるようにします。

実際には、リポジトリの同期を維持することは問題にならないことがわかると思います。要件が変更された場合は、インターフェイスを変更し、両方の実装を変更する必要があります。意図が変わった場合、単体テストが壊れ始めるポイントに到達する可能性があります。

お役に立てれば！

于 2009-10-10T20:38:28.393 に答える
2

FakeDinnerRepository が IDinnerRepository を必要とするコードをテストすることは何の価値もありません。DinnerRepository 自体はテストしないでください。実際のディナー リポジトリを使用して DinnerController などをテストすると、DinnerController の機能だけでなく、データ アクセス自体もテストすることになります。データ アクセス ビットは確実にテストする必要がありますが、ディナー コントローラーのテストではテストしないでください。

データ アクセスのテストは、かなり物議を醸すトピックです。ほとんどの人が単体テストから除外する理由は、単純に実行に時間がかかるからだと思います。データベースにクエリを実行する必要があると、ほとんどの開発者が耐えたくないテストに膨大な時間が追加されます。

データ アクセスを単体テストでテストするか、より正式な機能テストでテストするかは、あなた次第です。しかし、それは確かにテストする必要があります。個人的には、データ アクセス層のトランザクション ユニット テストのファンです。クエリのみをテストしていることを確認し、ORM が想定どおりに機能していることをテストしないようにしてください (それが ORM の仕事です)。

于 2009-12-30T20:00:01.757 に答える