データベースに対してドメイン サービスをテストするために、他の人がどのようなアプローチをとるのか疑問に思っていました。ドメイン サービス自体をテストするために、ドメイン サービスで使用できる一連のモック リポジトリが既にあります。これらのモック リポジトリの構築の一部は、サンプルの集計と関連するエンティティを構築し、それ以外の場合はモデル内で使用されるのと同じビジネス ルールに対してそれらを検証することです。これは、インターフェイスが変更された場合に、エンティティ自体の潜在的な影響ポイントを検出するための優れた簡単な手段も提供します。
SQL ベースのリポジトリのライブ テストで見られる主な問題は、データベースの一貫性です。たとえば、テストが実行されると、「作成」の側面はすでに実行されています。データベースが元の状態ではなくなるため、それらを再度実行すると、明らかに障害が発生します。この種のテスト専用に使用されるミラーリングされたデータベースを作成することを検討していました。構造、プログラマビリティ、制約などを含む最小限のものになります。また、特定の確立されたテスト用に最小限のデータセットを提供します。私の考えでは、テストの実行を開始する前に、ベース データを使用してデータベースを「元の」状態にリセットするために呼び出すことができるストアド プロシージャを作成できます。
これは、機能が最初に検証された後、開発者のマシンではそれほど重要ではありませんが、ナイトリー ビルドの一部としてこれらのテストを実行することの重要性について詳しく調べています。これにより、テストが失敗した場合に、ターゲットの展開環境 (特にこの場合、テスト チームが使用する環境) を汚さないようにビルドを保留することができます。
必ずしもプラットフォームが重要だとは思いませんが、実装に固有の懸念がある場合に備えて、私の環境は次のようになります。
Windows 7 (開発) / Windows Server 2008 R2 (サーバー) Visual Studio 2008 Team Edition (C#) Microsoft SQL Server 2008 Standard (開発/サーバー)
チーム ビルドを使用してビルドを実行していますが、それはおそらく質問の範囲内の要因ではありません。