実際のデータベースに対するドメインサービスの単体テスト

Question

データベースに対してドメインサービスをテストするために、他の人がどのようなアプローチをとるのか疑問に思っていましたか？ドメインサービス自体をテストするためにドメインサービスで使用できる一連の模擬リポジトリが既にあります。これらのモックリポジトリの構築の一部は、サンプルの集計と関連エンティティを構築し、モデル内で使用されるのと同じビジネスルールに対して検証することです。これにより、インターフェースが変更された場合に、エンティティ自体の潜在的な影響ポイントを検出するための優れたシンプルな手段も提供されます。

SQLベースのリポジトリのライブテストで見られる主な問題は、データベースの一貫性です。たとえば、テストが実行されると、「作成」アスペクトはすでに実行されています。データベースが元の状態ではなくなるため、それらを再度実行すると明らかに障害が発生します。私は、この種のテストにのみ使用するミラー化されたデータベースの作成を検討していました。構造、プログラム可能性、制約などを含む最小限のものです。また、特定の確立されたテスト用に最小限のデータセットを提供します。私の考え方は、データベースを「元の」状態にリセットするために呼び出すことができるストアドプロシージャを作成できるということです。テスト実行の開始前にベースデータを含む状態。

機能が最初に検証された後、これは開発者のマシンではそれほど重要ではありませんが、ナイトリービルドの一部としてこれらのテストを実行することの重要性をさらに検討しています。テストが失敗した場合、ビルドはターゲットのデプロイメント環境を汚さないように抑えられます（具体的には、この場合、テストチームが使用する環境になります）。

必ずしもプラットフォームが重要であるとは思いませんが、実装固有の懸念がある場合、私の環境は次のようになります。

Windows 7（開発）/ Windows Server 2008 R2（サーバー） Visual Studio 2008 Team Edition（C＃） Microsoft SQL Server 2008 Standard（開発/サーバー）

チームビルドを使用してビルドを実行していますが、それはおそらく質問の範囲内の要因ではありません。

Answer 1

  

たとえば、テストが実行されると、＆quot;作成＆quot;アスペクトはすでに実行されています。データベースが元の状態ではなくなるため、それらを再度実行すると明らかに障害が発生します。

おそらく、ユニットテストをトランザクション対応にすることができます。テストを実行してロールバックすると、データベースは変更されません。

Springには、これを容易にするトランザクションユニットテストクラスがあります。トランザクションマネージャーが必要です。

Answer 2

SQL Server Express （I ' 2005年にそれを行ったが、2008年には「テストデッキ」のセットアップを試みなかった。ファイルとして保存されるデータベース。これらはソース管理にチェックインでき、テストヘルパークラスは（a）それらを一時フォルダーにコピーし、（b）それらを書き込み可能にし、（c）それらに接続できます。元の状態に戻すには、一時コピーを削除してa-cを繰り返します。

これは大きな痛みです。 （duffymoが提案したように）トランザクションでうまくいくことができます。トランザクションの問題点は、ネストされたトランザクションと分散トランザクションです。コード内のトランザクションに注意してください。

Answer 3

テスト実行の起動時に最初に実行されるテストコードで、多数のデータファクトリを作成できます。次に、トランザクションロールバックメソッドを使用して、元の状態に保ちます。 簡単にするには、すべてのテストクラスをサブクラス化し、そこにトランザクションアクセサーとロールバックコードを配置します。ロールバックコードは、すべてのテストメソッドの完了時に自動的に実行されるように設定できます。

Answer 4

データベースにアクセスしているリポジトリの単体テストを実際に実行している場合、単体テストは実行していません。これは役立つテストかもしれませんが、単体テストではありません。それは統合テストです。それを行い、それを統合テストと呼びたい場合、それはまったく問題ありません。ただし、リポジトリで適切な設計原則に従っている場合は、ユニットテストでデータベースをテストする必要はありません。

非常に簡単に言えば、リポジトリの単体テストは、リポジトリへの入力に基づいてデータベースで発生する広範な影響をテストすることではありません。リポジトリへの入力が、そのような値のセットを持つ共同作業者への呼び出しになることを確認することです。

おわかりのように、リポジトリは、コードの残りの部分と同様に、単一リポジトリ原則に従う必要があります。基本的に、リポジトリには1つだけのリポジトリがあります。これは、基になるデータアクセステクノロジレイヤー（通常はADO.Netですが、Entity FrameworkまたはL2Sなど）に対するドメインモデルAPIの懸念を仲介することです。 ADO.Net呼び出しの例に進むと、リポジトリはデータレイヤーのファクトリーであるという責任を負うべきではなく、代わりにADO.Netデータインターフェイス（具体的にはIDbConnection / IDbCommand / IDbParameterからの協力者に依存する必要があります）等）。単純にIDbConnectionをコンストラクターパラメーターとして取得し、1日呼び出します。これは、インターフェイスに対してリポジトリユニットテストを記述し、モック（または偽物、スタブ、または必要なもの）を提供し、必要なメソッドが順に入力されることを確認できることを意味します。この正確なトピックに関するMSブログをご覧ください-＆gt; http：// blogs.msdn.com/b/schlepticons/archive/2010/07/20/unit-testing-repositories-a-rebuttal.aspx

これは、今後のテストや設計で間違いを犯さないようにするのに役立ちます。

ところで：データベースを単体テストしたい場合は可能です。 Visual Studio Database Testsを使用するだけです。その構築されたINTO対VS2005以来です。これは新しいことではありません。しかし、私はあなたに注意する必要があります、それらは完全にユニットテストである必要があります。

Answer 5

コードがかなりデータベースに依存しない場合、単体テスト（統合テストではなく）にSQLiteなどのインメモリデータベースを使用すると、速度と使いやすさのメリットが得られます（テストセットアップでdbを初期化します）。