統合テストに実際のデータベースを使用するには？

Question

は、質問にはいくつかの提案された解決策がありました「アプリケーションでのSQLステートメントをテストする方法」 -

• RAMメモリを使用して - 私はテストが起こるステージング環境の構成を変更することはできません。
• H2を使用する - PostgreSQLモードでもあまり互換性がありません
• 同じデータベースを使用してテストを実行します。
• メモリ内モードを使用する - PostgreSQLにはメモリがありません。

第3のものは実行可能であり、私はTest Containersを見ましたが、これは実際には美しい解決策ですが、比較的新しいものです。その結果、当社はそれを採用することに懐疑的です。

Mybatisを使用してPostgreSQLにアクセスします。

もう1つの方法は、スキーマ全体を再作成して、テストの前に必要な表を移入することです。ここで問題は、私は作成し、同じ名前のテーブルを持つスキーマを削除することができます。名前の衝突を避けるためには、スキーマの名前を変更する必要があります。その結果、クエリでも名前を変更する必要があります。クエリを変更せずにダミーのスキーマを指すようにする方法はありますか？

Answer 1

テスト目的でデータベース構成を定義し、実際のデータベースベースに接続してテストを実行できます。テスト・クラスのデータベース構成をテストするためにアクセスする必要があります。

たとえば、springとhibernateを使用してデータベースに接続する場合は、テストデータベースに接続するtest hibernate configuration xmlファイルを定義できます。その後、あなたのテストクラスでは、次のようにこの設定ファイルを使用します。

@RunWith(SpringJUnit4ClassRunner.class) 
@ContextConfiguratiion({testHibernate.xml, testSpring.xml , .... }) 
@TestExecutionListeners({...}) 
public class TestClass { 
.... 
    @Test 
    public void test1(){ 
    ... 
    } 
} 

ので、あなたがあなたのクエリを実行するためのテストのhibernateセッションファクトリにアクセスすることができます。

Answer 2

クエリを変更しないでください。テストでは、アプリケーションで使用する接続URLのみを変更する必要があります。問題は、そのURLをどのように動作させるかです。

完全なテストカバレッジを得るには、同じデータベースが必要です（気付いたように、h2と他のインメモリDBはあまり互換性がありません）。 postgresにはメモリ内モードがないため、ライフサイクルを自分で管理する必要があります。あなたがしなければならないいくつかの決定があります。そのうちのいくつか：

• あなたからデシベルを取得します

  ：postgresの（インストール/ドッカ/放浪）を提供したり、設定を自動化するために、すべての開発者が必要ですか？

• テスト用のデータベースの準備方法：手動スキーマのセットアップとクリーンアップ？

• テスト間でDBをリセットする方法：再起動しますか？常にロールバックしますか？定義済みで別途定義されたコンテンツ？何らかの逆の操作ですか？

• これらのテストを高速にするにはどうすればよいですか？

あなたが問題の一部を解決することができますいくつかのツールがあります。

1. testcontainersあなたが デシベルを提供するのに役立ちます。

2. dbunit - テスト用のデータの準備に役立ちます。

   短所：

   • 多くの作業を作成して、スキーマとデータを維持するために必要とされます。特にあなたのプロジェクトが集中的な開発段階にあるときは特にそうです。
   • それは突然、あなたがこのツールによってサポートされていないいくつかのDBの機能を使用したいので、もし、それ

3. testegrationをテストすることは困難である別の抽象化レイヤです - テントあなたがフル提供するために、使用する準備ができてと拡張可能なライフサイクル（開示：私は創作者です）。

   短所：

   • だけ小さなプロジェクト
   • 非常に若いプロジェクト

のための無料のあなたも、あなた自身のギャップを埋めることができます。いつものようにそれは貿易です：時間対金銭