統合テストでデータベースにヒットしてもよろしいですか？

Question

私は統合テストで非常に具体的な状況があります。

私はスプリングブートを使用していくつかのマイクロサービスで構成されたレストAPIを開発しています。これらのサービスの中には、基本的に、UIアプリケーションによってアクセスされるか、または内部の検証/クエリに消費されるための操作が難しいものがあります。

すべてのデータベースの操作は、従来のライブラリ（jpaはありません）によって行われ、非標準のデータベースを使用しています。良い例は実際のデータベースを使わないと言いますが、このシナリオでは、テスト時にダミーデータベースをどのように使用するのか想像できません（dbunitやh2など）。この方法で：

1 - 統合テストで実際のデータベースにヒットするのはいいですか？

1がOKであれば、私は別の質問があります。

通常、私たちはユニット/統合テストでのデータの状態を変更しないと。テストはお互いに独立していなければなりません。

私の場合、私はポストメソッドのレスポンスでエンティティIDが何であるかを知っているだけなので、get/put/deleteメソッドを実装するのは難しいです。もちろんget/put/deleteメソッドでは、最初に挿入して別の操作を行うことはできますが、この観点では、最後にテストの開始時とは異なる状態のデータベースを作成します。このように、別の質問があります：

2 - どのように私はテストの前に同じ状態にデータベースを回復することができますか？

私はそれが特定の状況である可能性があることを知っていますが、このシナリオをうまくテストするエレガントな方法を見つけるためには本当に助けに感謝します。

ありがとうございます。

Answer 1

インターフェイス統合テストにインメモリH2データベースを指定し、特定のテストに必要に応じてデータを入力できます。これは、Jenkinsや類似の単体テストシステム上のデータベースが意味をなさない状況で実行している場合に便利です。実際には、エンド・ツー・エンドの統合、または細粒度の統合をテストしているかどうかによって異なります。

Answer 2

異なった質問をする必要があります：プロダクションデータベースに対してテストを実行するためのリスクはありますか？

意味：テストでコード内の問題のみが判明した場合、誰もが満足します。

しかし、あなたが台無しにしてデータベースが真剣に壊れてしまい、最初は失敗したバックアップのためにサイト全体を取り除く必要があります...あなたのビジネスは2日間オフラインになるので、あなたのマネージャーはどうなると思いますかそんな？

ロングストーリーショート：それは依存します。あなたがリスクを含むことができれば - はい。しかし、そうでない場合は、他の選択肢を探してください。少なくとも、あなたのマネージャーがあなたがしていることを理解していることを確認してください。

Answer 3

統合テストはうまくいきます。実稼働環境でそれらを実行しない限り、私は言うでしょう。これにより、アプリケーション全体をテストしたり、レスポンス、シリアライゼーション、およびデシリアライゼーションをどのように処理するかをテストできます。テストケースでは、本番データベースに期待する内容を処理し、すべてのテストテストを分離し、テストケースで作成したものを元の状態に戻した後で削除する必要があります。そうしないと、テストケースが衝突する可能性があります。ローカルデータベースまたは専用のテストデータベースで統合テストをテストします。