1

MVC4 C# Web サイトでは、単体テストを使用してコードをテストしています。現在行っていることは、モック データベースを作成してから、各レイヤーをテストすることです。

  1. データベースのテスト - 接続、初期化、ロードなど
  2. データベースにアクセスするコードをテストする
  3. ビューレイヤーをテストする

これら 3 つのカテゴリを順番に実行し、前のカテゴリが合格した場合にのみ実行したいと考えています。これは正しい方法ですか?依存性注入フレームワークを使用していた古い方法は、模擬テストに対する奇妙なアプローチでした。実際には、各データ アクセサーに対してモック クラスを作成しましたが、各メソッドのロジックを再実装する必要があるため、これは面倒であり、実際には何の価値も追加しませんでした。ちょっと待って。

4

1 に答える 1

3

これら 3 つのカテゴリを順番に実行し、前のカテゴリが合格した場合にのみ実行したいと考えています。これは正しい方法ですか?

いいえ。すべてを個別にテストする必要があります。そのため、失敗したデータ アクセス コードはビューとは完全に無関係である必要があります。したがって、ビュー ユニット テストはまったく別の理由で失敗するはずです。そのため、常にすべてのテストを実行する必要があります。

一般に、テストは分離して実行する必要があり、他のテストに依存するべきではありません。ビューレイヤーはまだデータアクセスコードに依存しているようですが、下のレイヤーのみを抽象化したようです。その場合、ビューの観点からは、間接的な依存関係をモックしているため、単体テストが必要以上に複雑になります。

依存性注入フレームワークを使用していた古い方法は、模擬テストへの奇妙なアプローチでした

これが得られるかどうかはわかりませんが、単体テスト内で DI コンテナーを使用しているようです。これは絶対ダメです。DI フレームワークでテストを乱雑にしないでください。そして、その必要はありません。依存性注入の原則に基づいてクラスを設計するだけで (すべての依存性をコンストラクターの引数として公開する)、テストでは偽の依存関係を使用してテスト対象のクラスを手動で新しくするだけです。または、これが反復的なコードにつながる場合は、テストでファクトリ メソッドを作成します。テスト中のクラスの新しいインスタンスを作成するクラス。

実際には、各データアクセサーに対してモッククラスを作成しましたが、これは最悪です

よくわかりませんが、ここであなたのデザインに何か問題があるように聞こえます。通常、 やIRepository<T>などの複数の実装を持つインターフェイスがあります。テスト スイートには、1 つのジェネリックorがあり、これで完了です。ここで多くのクラスをモックする必要はありません。UserRepository : IRepository<User>OrderRepository : IRepository<Order>FakeRespository<T>InMemoryRepository<T>

絶対に読むべき2冊の素晴らしい本を次に示します。

  1. 単体テストの芸術
  2. .NET での依存性注入

それらの本はあなたの人生を変えるでしょう。とにかく読むことになるので、この本も読んでください(質問とは関係ありませんが、コードも人生を変えるものです)。

于 2012-10-31T19:49:16.093 に答える