質問: 私が持っている状況はこれです: 1. 私はリポジトリパターンを実装していないASP.NET MVCプロジェクトに取り組んでいます 2. すべての`DbContext`呼び出しは、コントローラレイヤーから行われます。 3. `DbContext`はusingステートメントでラップされ、メモリ管理目的で必要に応じてインスタンス化されます。 4. これらのコントローラをユニットテストする必要があります。これは、 `DbContext`をコントローラに注入することを意味します。 5. 私たちはIoCコンテナを使用していません。私は、パラメータのないコンストラクタで新しいインスタンスを作成し、コントローラのアクションへの呼び出しの寿命のためにそれを使用する必要があります。 6. 私はこれらの条件のほとんどを変更することはできません。 私が変更できる条件: 1. 信頼できるオプションが代わりに使用できる場合は、usingステートメントを削除します。 2. このコードはそのままの状態ではテスト可能ではなく、他の場所でエネルギーを使うようにしてください。 だから、私の質問はこれです:どのように返される応答を模擬することができますが、これらのお互いに矛盾する傾向があるので、ステートメントの信頼性を維持するためにコンストラクタに`DbContext`を渡すか。 要求されたアクションの実行が完了するたびにコンテキストが破棄されることを保証する方法がある限り、私は`using`ステートメントの`using`をやめる必要がある場合は大丈夫です。 これについて何か考えていますか?
回答: テストするメソッド内でDbContextを作成することは、コード内の依存関係の具体的なインスタンスをインスタンス化することと変わりありません。つまり、擬似依存関係でテストすることはできません。ですから、すぐにできるオプションは(コード/構造の変更なしで)です: * ユニットテストのために、EFをポイントするインメモリデータプロバイダを実装します。 * テスト実行の間にリストアできる既知の状態のデータベースを設定します。 (統合テストの多くは、非常に迅速に実行できるテストが必要なTDDにはあまり適していません。) * DI / IoCが不足しているため、「ユニットテスト用に設計されていません」バケットに入れてください DbContextをモックするのは面倒ですが、できることはありません。ひとたびモックが可能になったら、AutofacのようなIoCコンテナをプロジェクトに追加することをお勧めします。私はあなたがIoCコンテナを導入することを妨げる状況を知りませんが、もしチームがそれがすべてか何かの再要因であり、大きすぎる仕事をしていることを心配しているなら、私はそれをプロジェクトへの変更を最小限に抑えながら、既存のコードを壊さないように追加することができます。 DbContextとは別に、コードがDI / IoC Containerを使用していない場合、他の具体的な依存関係をどのように処理する予定ですか?一度に*すべての*依存関係/コントローラを切り替える必要はありませんが、徐々にそれらを改善します。 コンテナがMVCコントローラを解決するように設定されると、デフォルトコンストラクタを持つ既存のコントローラは影響を受けません。コンテナにDbContextを登録し、テスト中のコントローラをコンストラクタ内のコンテキストを受け入れるように調整します。 IoCコンテナは、DbContextのライフタイムスコープをリクエストごとのインスタンスに設定するので、 `using {}`ブロック`using {}`する必要はありません。そこからテストで疑似DbContextが提供され、コンテナはコンテキストのライフスパンを管理します。 私は最近、Lazy dependencies / w Autofacを使用して複数の依存関係を持つクラスのテストを作成する記事を投稿しました。 https://medium.com/@StevePy/writing-easily-testable-code-with-autofac-lazy-properties-f9c63457c8ceで読むことができます