c# - データと対話するためのクラスをどのように単体テストしますか?

Question

インターフェイスから派生した、さまざまな種類のデータと対話するためのリポジトリ クラスがいくつかありIRepositoryます。

実装では、コードはデータ ソース (XML ファイルのディレクトリ、データベース、または単なるキャッシュ) と対話します。これらの実装のいずれかを確実に単体テストすることは可能ですか? 実際のコードではなくモックコードのみをテストしているため、モック実装が機能しているとは思えません。

Answer 1

いいえ、. を使用するクラスを作成するときにモックを使用しIRepositoryます。の実装についてはIRepository、適切なデータ ソースに対してテストする必要があります。データベースの場合、これは少し面倒ですが、ファイル システムの場合は、それほど苦痛ではありません。

可能であれば、ストリームまたはリーダーの観点から実装を表現できれば、作業が楽になります。実装のこれらの部分のテストは、インメモリ データ ソース、またはテスト アセンブリ内のリソースからのストリームに対して行うことができます。もちろん、実際のデータベースまたはファイル システムに行くいくつかのテストが必要になるでしょう。

そのようなテストを「単体」テストと呼ぶかどうかは、単体テストをどのように定義するかの問題です。個人的には、関連する名前についてはあまり気にしませんが、テストを行うことには関心があります。特にデータベースの場合、これらは多少苦痛になる可能性があります (特に、テストを並行して実行できるようにしたい場合)。しかし、私の経験では、非常に価値がある場合もあります。

Answer 2

実際にデータを永続化またはクエリするコードをテストしている場合、おそらく実際にはデータベースにアクセスしたいと思うでしょう。

これらは単体テストではなく統合テストです。

データの状態を把握しているテスト データベースをセットアップし、これに対してテストを実行できます。また、単体テストとは異なり、チェックインのたびに実行する必要がないことをテストに伝えたい場合もあります (nUnit では、実行しないように指示する属性でテスト クラスを装飾できます)。

Answer 3

大まかに言えば、データ ソースとの対話のみを目的とするコードは単体テストしません。リポジトリを自動的にテストしたい場合もありますが、そのようなテストは定義上統合テストになります。「最初のパス」ビルドの一部としてこれらのテストを実行したくない場合があります。たとえば、データベースのセットアップと自分でのクリーンアップにかなりの時間がかかる可能性があるためです。

リポジトリに他の責任がある場合 (Unit of Work パターンの実装など)、それらを個別に単体テストすることをお勧めします。

Answer 4

IRepository の実装のある時点で、データベース/ファイル/xml に対して実際に読み取り/書き込みを行うサード パーティ API を使用します。あなたがしたいことは、それらの API をモックして、コードが正しい API を正しい順序で呼び出すようにすることです。

したがって、データベースから読み取る場合は、SqlConnection と SqlCommand をモックして、それらのクラスで正しいメソッドを呼び出すようにします。ストリームに書き込んでいる場合は、ストリームをモックして、それをフラッシュして破棄するようにすることができます (たとえば)。