統合テストではデータベースを使用する必要がありますか？
統合テストはプロジェクトの一部をテストすることを知っています。そして、私はこの相互作用をテストする必要があります。そして質問があります：
1）これらのテストでは実際のデータベースデータを使用する必要がありますか？実際のデータベースに接続する必要があるということですか？
2）共通データベースは使用できないと思います。これにはプライベートデータベースを使用する必要がありますが、大学には私のデータベースがないため、テストを使用できません。次に何をすべきか？
3）実際のデータをコントローラーに渡す必要がありますか、それともランダムなデータを考え出すことができますか？データベースのデータに同じ質問。実際の場合、ブラウザなどからデータを取得する必要があります...
4）単体テストでこの相互作用をテストした場合、これらの統合テストは本当に必要ですか？実際のデータの代わりにモックを使用しました。
5）統合ではなくシステムテストではないですか？
6）統合テストでは、常に実際のデータを使用する必要がありますか？
1）これらのテストでは実際のデータベースデータを使用する必要がありますか？実際のデータベースに接続する必要があるということですか？
ソフトウェアとデータベースの統合をテストする場合は、実際のデータベースを使用する必要があります（理想的には、本番環境で使用するバージョンまで）。データベースがテストの一部であると想定されていない場合は、他のストレージメカニズムで置き換えることができる場合があります（アダプターパターンまたはデータベースアブストラクションライブラリを使用している場合は可能です）。手動でクエリを作成する場合、SQLはデータベースに依存している可能性が高いため、別のデータベースを代用することはできません。
2）共通データベースは使用できないと思います。これにはプライベートデータベースを使用する必要がありますが、大学には私のデータベースがないため、テストを使用できません。次に何をすべきか？
テストに使用するデータベースは、テスト実行中のテストにのみ使用してください。その後、それをクリアして、別のテスト実行に使用できます。したがって、専用のテストデータベースが必要です。理想的には、このDBは開発マシンでローカルに実行されますが、集中管理することもできます（独自のライセンスに準拠する必要がある場合でも必要になる場合があります）。
ソフトウェアは異なる本番データベースとテストデータベースで実行されるため、特定のデータベースを構成可能にする必要があります。環境変数から接続文字列を読み取る。バージョン管理にチェックインされている構成ファイルには、環境間で異なる情報を構成ファイルに含めないでください。代わりに、プライベート構成を使用する方法を実装します。コマンドライン引数または環境変数として構成を提供する。もちろん、構成テンプレートや特定の環境の構成をチェックインしても問題ありません。本番構成。
3）実際のデータをコントローラーに渡す必要がありますか、それともランダムなデータを考え出すことができますか？データベースのデータに同じ質問。実際の場合、ブラウザなどからデータを取得する必要があります...
法律上の制約により、実際のデータを使用できない場合があります。 HIPAAやGDPRなどのプライバシー規制。また、メールの送信やサードパーティのシステムに対する請求など、テストの設定にバグがある場合、実際のデータが実際のアクションを誤って引き起こす可能性もあります。
代わりに、シナリオをシミュレーションしてそのデータを使用することをお勧めします。ソフトウェアにユーザーインターフェイスがある場合は、手動でシナリオを再生し、このデータをキャプチャして後で再生できます。また、デバッグレベルのログファイルを解析し、個人データ（正確なタイムスタンプ、IPアドレス、名前、メールなど）から手動でスクラブしてテストデータを収集しました。
4）単体テストでこの相互作用をテストした場合、これらの統合テストは本当に必要ですか？実際のデータの代わりにモックを使用しました。
モックを使用した場合、インターフェースの半分をテストしましたが、両方の半分のインターフェースの統合はテストしませんでした。これは、電気ソケットに電力が供給されていることをテストしたり、プラグが正しい形状であることをテストしたりするものですが、デバイスをソケットに差し込んだときにデバイスが動作するかどうかをテストするものではありません。
単体テストは、コンポーネントを個別に注意深くテストするのに非常に役立ちますが、通常、主要なテスト戦略としては適していません。特にWebアプリの場合、通常、エンドツーエンドのテスト（おそらく統合またはシステムテストの規模）を実行する方がはるかに簡単です。関連するブラウザ自動化ツールが広く利用可能であり、REST APIをテストするだけの場合はさらに多くのツールがあります。
5）統合ではなくシステムテストではないですか？
統合テストでは、すべてではなく一部のコンポーネントを統合します。他のコンポーネントはスタブに置き換えられます。システムテストには、すべての実際のコンポーネントが含まれます。通常、統合テストでは依然としてサードパーティのサービスが除外され、ローカルコンポーネントのみが統合されます。
システムのどの部分を一緒にテストするかを検討する必要があります。
これは、作成したコードを検証するだけで、返される任意のデータに基づいて正しいアクションが実行されるのですか？サービスのエッジをテストして、外部サービスに対して正しいクエリが形成され、クライアントへの応答が正しくフォーマットされていることを確認していますか？
作成したコードのみをテストする場合は、アプリケーションの外部依存関係を模擬し、それらのサービスへの予期される呼び出しのシナリオを作成すると便利です。次に、その依存関係が正しいリクエストを受け取った場合に、返信定型文を返すことができます。
したがって、おそらくアプリケーションがデータベースを呼び出すときに、DBクライアントをモックして、Select * from Orders where product_name = 'foo'のクエリを受け取ったかどうかを確認し、実際の応答を表すOrdersのセットを返すことができます。あなたのデータベースが与えるでしょう。
テストはおおよそこのように実行されます。
- アプリケーションAPIを呼び出す
- 通常の本番ロジックを実行する
- モックされた外部依存関係が何かの呼び出しを受け取ります
- 外部呼び出しが正しいことを確認してから、事前に作成された応答を返す
- アプリケーションの応答が予想と同じであることを表明する
OWINを介してホスティングするアプリケーションを抽象化すると、アプリケーションのメモリ内インスタンスを作成でき、モックでコンテナをオーバーライドすることにより、これを非常にエレガントに実現できます。
https://www.strathweb.com/2013/12/owin-memory-integration-testing/