良い設計上の理由から、DbConnectionsで作業する必要のある.NETクラスを単体テストしようとしています。これらのテストでは、これらのクラスへの入力として特定のデータをメモリに格納しています。Dbを使用しないDbConnectionで、メモリ内のDataSet（または同様のもの）をソースとして使用
メモリ内のデータはDataTable（またはそのDataTableを含むDataSet）として簡単に表現できますが、別のクラスが適切な場合はそれを使用できます。
メモリ内のデータへの接続を表すDbConnectionを魔法のように取得できた場合、オブジェクトを作成し、メモリ内のデータに対してクエリを実行し、出力が一致するようにすることができます期待。 DbConnectionをメモリ内のデータに取得する方法はありますか？私は、これを実現するために追加のサードパーティソフトウェアをインストールする自由を持っておらず、理想的にはテスト中にディスクに触れたくありません。
DbConnectionを消費するのではなく、IDbConnectionを消費して模擬しますか？同様のことを行い、DataSetを模擬します。 DataSet.CreateDataReaderは、DbDataReaderから継承するDataTableReaderを返します。
DbDataReaderと同じインターフェイスを実装するクラスを返すExecuteReader（）メソッドを追加した独自のIDbConnectionのようなインターフェイスでDbConnectionをラップしました。私たちのモックでは、ExecuteReaderは単にDataSet.CreateDataReaderが提供するものを返します。
ラウンドアバウトのように聞こえますが、多くの結果セットを含むデータセットを構築することは非常に便利です。私たちは、結果を表すストアドプロシージャの後にDataTablesを命名し、クライアントが呼んでいるプロセスに基づいてIDbConnectionモックを右のDatatableで取得します。 DataTableはCreateDataReaderも実装していますので、ぜひお試しください。
TypeMock？ （あなたはそれをインストールする必要があります）。
Data *がテストのための適切なフックを与えることができます - 一般的にかなり悪いケースであることに注意してください。しかし、あなたはGood Design Reasonsと言っているので、それはすべて対象です：D
私が使用したアプローチは、メモリ内のSqliteデータベースを作成することです。これは、System.Data.SQLite.Core NuGetパッケージを単体テストプロジェクトに引き込むだけで簡単に実行できます。他の場所にソフトウェアをインストールする必要はありません。
本当に明白なアイデアのように聞こえますが、Dapper単体テストを見てから自分でこのテクニックを使うと思っていました。あなたは、メモリ内sqliteのDBを作成し、作成したテーブルを取り込む場合は、あなたがいない前に接続を閉じるように注意する必要があるということであると認識することが
ことの一つに「GetSqliteConnection」メソッドを参照してください。新しいメモリ内接続を開くと、新しいメモリのでないのメモリに接続するため、テストクエリを実行します。テスト用に丁寧に準備したデータベース！いくつかのテストでは、この落とし穴を避けるために接続を開いたままにするカスタムIDbConnection実装を使用します。
https://github.com/ProductiveRage/SqlProxyAndReplay/blob/master/Tests/StaysOpenSqliteConnection.cs