インメモリデータベースは統合テストの一種ですか？

Question

単体テストでのインメモリデータベースの使用に関するほとんどの回答を調べましたが、明確なものは見つかりませんでした。

私たちはコードベースのいくつかをカバーするためにいくつかのユニットテストを書いています。コードベースはASP.NET CoreおよびEF Coreで記述されています。私はxUnitとMoqを使用しています。

単体テストと統合テストの概念を読み、理解しました。

私が理解しているように、単体テストを作成することは、他の依存関係から分離してコードをテストすることを意味し、これを実現するために、それらの依存関係をモックしてコードのみをテストできます。

ただし、特にこれらの依存関係がリポジトリ依存関係である場合に必要な依存関係のモックを設定するのは少し手間がかかることがわかりました。

インメモリデータベースを使用しようとしたときに必要なことは、インメモリデータベースのセットアップ、データベースのシード、テストフィクスチャの作成だけでした。その後のテストでは、依存関係を作成するだけで問題なく動作します。

リポジトリをモックするには、モックと戻り値を設定する必要があります。そして、ここで説明されているように、非同期リポジトリをモックする複雑さがあります： Entity Framework Coreで非同期リポジトリをモックする方法。テストごとに、必要なリポジトリをモックする必要があります。つまり、より多くの作業が必要になります。

これらすべてを念頭に置いて、モックを捨ててメモリ内データベースを使用する方が良いでしょうか？また、これはインメモリデータベースですが、統合テストとは見なされません。

インメモリデータベースとモッキングを使用して2つの異なるテストを作成しました。インメモリデータベースのテストには当然より長い時間がかかりましたが、通常、モックを使用したテストよりも約1秒長くなっています。

Doc Brown · Accepted Answer

私見あなたは間違った質問をしています。作成したものが、一部の人による単体テストと呼ばれる場合でも、他の人による統合テストと呼ばれる場合でもかまいません。ここで重要なのは

このテストはあなたのケースに役立ちます（これは、特定の欠陥を回避するのに役立ち、根本的な原因となるコードの領域を十分に減らします）特定の欠陥があるかもしれません）？
この種類のテストをいくつか実行する場合でも、十分高速ですか？（1秒長くてもあまり聞こえませんが、元のテストで0.001秒が必要で、新しいテストでは1.001秒が必要な場合、この種類のテストを5000回実行すると大きな違いが生じます）
それは保守可能ですか？理想的には、代替アプローチよりも保守しやすいですか？これは、ツールと「メモリ内DB」のサポート状況に大きく依存します。

これらの質問すべてに「はい」で正直に答えられる場合は、先に進んでください。

推奨： The Way of Testivus -たとえば、ドグマを少なくするように指示します（これはテストだけでなく、優れた推奨事項です）。

amon · Answer

インメモリデータベースは、単体テストと統合テストの両方に役立ちますが、正確には何をしようとしているのかによって異なります。

単体テストは単一のコンポーネントをチェックします。理想的には、そのユニットは他のコンポーネントから分離してテストされますが、厳密には必要ありません。ユニットテストで他のテスト済みコンポーネントを使用しても、便宜上問題ありません。分離されたテストはより高速に実行され、エラーの原因に近づく傾向がありますが、ソフトウェアがテスト可能性のためにdesignedでない限り、たとえばコンポーネント間の依存関係を最小限に抑えてコンポーネントを接続することによってセットアップするのは難しい場合があります小さく、モックしやすいインターフェース。

統合テストでは、コンポーネント間の相互作用をチェックします。ただし、そのテストのコンテキストに関係のないコンポーネントは、モックアウトすることができます。しかし、繰り返しになりますが、これは速度とエラーの特定化と利便性のトレードオフです。一部のテストは設定が非常に難しいため、設定する価値がありません。

インメモリデータベースは、完全なデータアクセス層を模擬したくない場合、またはORMのために実際のデータベースが必要な場合に、単体テストと統合テストの両方に役立ちます。ここでは、インメモリデータベースを使用すると、セットアップが簡単で高速になり、テストごとに新しいデータベースをセットアップすることで、テスト間の分離を簡単に実現できます。

ただし、これはソフトウェアと実際のデータベースとの統合をテストしません。これらの違いはSQL方言などにより大きくなる可能性があります。したがって、テスト計画には、実際のデータベースソフトウェアを使用したテストも含める必要があります。ステージング環境で。

実際には、単体テストと統合テストを明確に区別することはあまり重要ではありません。優れた自動化されたテストスイート、およびおそらく再現可能な手動テストのためのツールと手順を用意することがより重要です。個人的には、テスト対象のソフトウェアのvalueを実証しやすくし、ソフトウェアが全体として機能するという信頼性が高まるため、私はほとんど統合テストを書いています。 BDDスタイルの統合テストは特に役立ちますが、細かいTDDスタイルの単体テストの使用を想定しています。