2

私たちはASP.NET MVCサイトを構築しています.ユニットテストを最も有効にするために接続を定義する場所に苦労しています.トランザクションとデータベース操作を管理できるデータ コンテキスト)。

3 つのクラスがあるとします。

UserController
UserService
UserRepository

以前は、UserService のメソッド内で次のようなことを行っていました。

Using (ISomeSession session = new SomeSession())
{
  session.StartTransaction();
  IUserRepository rep = new UserRepository(session);
  rep.DoSomething();
  rep.Save();
  session.Commit();
}

ただし、SomeSession への依存関係が挿入されていないため、これを単体テストすることは実際には不可能でした。ただし、DI を使用して UserService に依存関係を挿入すると、セッションは UserService の存続期間中ハングアップします。UserController から複数のサービスが呼び出された場合、UserController がガベージ コレクションされるまで、それぞれのサービスがハングアップする可能性があります。

これをより適切に管理する方法について何か考えはありますか? 明らかな何かが欠けていますか？

編集

わかりにくかったらすみません。セッション/データ コンテキストで依存性注入を使用できることは理解していますが、サービス クラスの存続期間中は維持されます。実行時間の長いアクション/メソッド (つまり、サービスがバッチ プロセスによって呼び出されているとしましょう) の場合、テスト容易性を追加する以外の理由で、多くのオープン セッションが発生する可能性があります。

4

2 に答える 2

2

RichardODが正しく観察したように、単体テストの作成にライブデータベース接続を使用することはできません。あなたがそれをしているなら、あなたは統合テストです。

リポジトリインターフェイス、1つの実際のリポジトリ、および単体テスト用の1つの偽のリポジトリに別々の実装があります。偽のリポジトリは、実際のデータコンテキストではなく、汎用リストで機能します。私はDIを使用して（Ninjectを使用して作業をより快適にしますが、手動でも同様に実行できます）、正しいリポジトリーを注入します。

実際の接続を使用して単体テストを行っている例はごくわずかですが、これはリポジトリクラスの単体テストであり、コントローラー、UI、またはビジネスレイヤーオブジェクトの単体テストではありません。

編集：あなたが追加したコメントで、私はあなたが実際に何を求めていたかを理解したと思います。先週私がまったく同じテーマに取り組んだので、あなたはそれについて何か質問するでしょう:-)

非常に薄いラッパー内でデータコンテキストをインスタンス化し、そのコンテキストをHttpContext.Current.Itemsディクショナリ内に配置します。このように、コンテキストはグローバルですが、現在のリクエストに対してのみです。

それでも、あなたの質問の主題は非常に誤解を招くものです。あなたは「ユニットテストのためにデータコンテキストをインスタンス化する場所」を尋ねていましたが、答えは通常はそうではないということです。私の単体テストはまだ偽のリポジトリで動作します。

于 2009-08-10T10:21:16.327 に答える
-2

最も簡単な方法は、開発および運用用に web.config で定義した接続文字列を用意することです。Unittests の場合、Testproject の app.config で定義します。

于 2009-08-10T10:02:30.107 に答える