そこで、すべてのpostgresクエリがH2で機能すると考えて、H2 PosgreSQL互換モードを使用することを考えました。間違っている場合は、修正してください
それは真実ではないのではないかと思います。
H2はPostgreSQL構文をエミュレートし、いくつかの機能と拡張機能をサポートしようとします。 PostgreSQLの動作と完全に一致することはなく、すべての機能をサポートしているわけではありません。
あなたが持っている唯一のオプションは次のとおりです：
- テストでPostgreSQLを使用します。または
- H2でサポートされていない機能の使用を停止する
テストにはPgを使用することをお勧めします。 initdbがpostgresインスタンスであり、テスト用に起動してから破棄するテストハーネスを作成するのは比較的簡単です。
コメントに基づいて更新：
「ユニット」テストと「統合」テストの間に明確な境界線はありません。この場合、H2も外付け部品です。純粋主義者の単体テストには、テストハーネスの一部としてクエリに対するダミーのレスポンダーがあります。 H2に対するテストは、PostgreSQLに対するテストと同じくらい「統合」テストです。インプロセスでインメモリであるという事実は便利ですが、機能的には重要ではありません。
単体テストを行う場合 「PostgreSQL」、「SybaseIQ」などのターゲットと一緒に使用するために、アプリ用に別のデータベースターゲットを作成する必要があります。それを「MockDatabase」と呼びます。これは、クエリから期待される結果を返すだけです。実際にはクエリを実行せず、残りのコードの動作をテストするためにのみ存在します。
個人的には、これは時間の大きな無駄だと思いますが、ユニットテストの純粋主義者がテストハーネスに外部依存関係を導入することを避けるために行うことです。
DBコンポーネントの（統合ではなく）ユニットテストを要求するが、モックインターフェイスを作成できない、または作成できない場合は、代わりに既存のインターフェイスを使用する方法を見つける必要があります。 H2はこれに適した候補ですが、H2で機能する新しいクエリのセットを使用して新しいバックエンドを作成する必要があり、PostgreSQLバックエンドを再利用することはできません。すでに確立しているように、H2はPostgreSQLで使用する必要のあるすべての機能をサポートしているわけではないため、H2で同じことを行うためのさまざまな方法を見つける必要があります。 1つのオプションは、実際のアプリケーションのスキーマを完全に無視して、「期待される」結果とそれらの結果を返す単純なクエリを使用して単純なH2データベースを作成することです。ここでの唯一の本当の欠点は、維持するのが大きな苦痛になる可能性があることです...しかし、それは単体テストです。
個人的には、PostgreSQLでテストするだけです。狭いインターフェイスの明確に定義されたユニットとしてスタンドアロンである個々のクラスまたはモジュールをテストしない限り、誰かがそれを「ユニット」テストと「統合」テストのどちらと呼んでもかまいません。たとえば、データ検証クラスの単体テストを行います。データベースインターフェイスコードの場合、純粋主義者の単体テストはほとんど意味がなく、統合テストを行うだけです。
そのためには、インプロセスのインメモリデータベースがあると便利ですが、必須ではありません。セットアップコードinitdbになるように、テストハーネスを作成できます。 ■新しいPostgreSQLを起動します。次に、ティアダウンコードはポストマスターを強制終了し、datadirを削除します。これについては、この回答で詳しく説明しました。
参照：
- メモリ内でのみPostgreSQLを実行する
に関して：
予想される終了データセットを含むすべてのクエリがPostgressで正常に機能する場合、他のすべてのデータベースでも正常に機能すると想定できます
あなたが正しく言っていることを私が理解しているなら、そうです、そうです-あなたのコードの残りの部分 PostgreSQLのデータセットで動作しますが、通常、別のデータベースの同じデータを含むデータセットでも同じように動作するはずです。もちろん、データベース固有の機能ではなく、単純なデータ型を使用している限り。