メモリ内でのみPostgreSQLを実行する

私が書いたユニットテストごとに、メモリのみで実行される小さなPostgreSQLデータベースを実行したいと思います。例えば：

@Before
void setUp() {
    String port = runPostgresOnRandomPort();
    connectTo("postgres://localhost:"+port+"/in_memory_db");
    // ...
}

理想的には、単体テストで使用するバージョンコントロールに単一のpostgres実行可能ファイルをチェックインします。

のようなものHSQLですが、postgres用です。どうやってやるの？

そのようなPostgresバージョンを入手できますか？ディスクを使用しないように指示するにはどうすればよいですか？

これはPostgresでは不可能です。HSQLDBやMySQLのようなインプロセス/インメモリエンジンは提供していません。

自己完結型の環境を作成する場合は、PostgresバイナリをSVNに配置できます（ただし、単一の実行可能ファイルだけではありません）。

これで何かを行う前に、initdbを実行してテストデータベースをセットアップする必要があります。これは、バッチファイルから、またはRuntime.exec（）を使用して行うことができます。ただし、initdbは高速ではないことに注意してください。あなたは間違いなく、各テストに対してそれを実行したくないでしょう。ただし、テストスイートの前にこれを実行することもできます。

ただし、これは可能ですが、専用のPostgresをインストールして、テストを実行する前にテストデータベースを再作成することをお勧めします。

テンプレートデータベースを使用してテストデータベースを再作成できます。これにより、データベースを非常に高速に作成できます（各テスト実行でinitdbを実行するよりもはるかに高速です）。

（インメモリPostgreSQLの使用から私の回答を移動して一般化する）：

あなたはインプロセス、インメモリでPgを実行することはできません

テストのためにインメモリPostgresデータベースを実行する方法がわかりません。出来ますか？

いいえ、できません。PostgreSQLはCで実装され、プラットフォームコードにコンパイルされます。H2やDerbyとは異なり、jarをロードして使い捨てのインメモリDBとして起動することはできません。

Cでも記述され、プラットフォームコードにコンパイルされるSQLiteとは異なり、PostgreSQLもインプロセスでロードできません。マルチスレッド化ではなくマルチプロセッシングアーキテクチャであるため、複数のプロセス（接続ごとに1つ）が必要です。マルチプロセッシング要件手段は、あなたがしなければならないスタンドアロン・プロセスとしてのpostmasterを起動します。

代わりに、接続を事前設定してください

特定のホスト名/ユーザー名/パスワードが機能することを期待してテストをCREATE DATABASE作成し、使い捨てデータベースをテストハーネスDROP DATABASEに設定して、実行の最後に実行することをお勧めします。プロパティファイルからデータベース接続の詳細を取得し、ターゲットプロパティ、環境変数などをビルドします。

単体テストに指定するユーザーがスーパーユーザーではなく、CREATEDB権限を持つユーザーである限り、気になるデータベースがすでに存在する既存のPostgreSQLインスタンスを使用しても安全です。最悪の場合、他のデータベースでパフォーマンスの問題が発生します。そのため、テストのために完全に分離されたPostgreSQLインストールを実行することを好みます。

代わりに、使い捨てのPostgreSQLインスタンスをテスト用に起動します

あなたがしている場合は別の方法として、本当にあなたは可能性が熱心持っているあなたのテストハーネスを見つけinitdbおよびpostgres実行バイナリ、initdb修正、データベースを作成するのpg_hba.confにtrust実行し、postgresDBを作成し、ユーザーを作成し、ランダムなポート上で起動して、テストを実行します。複数のアーキテクチャのPostgreSQLバイナリをjarにバンドルし、テストを実行する前に、現在のアーキテクチャのバイナリを一時ディレクトリに解凍することもできます。

個人的には、それは避けなければならない大きな痛みだと思います。テストDBを構成するだけの方が簡単です。ただし、でのinclude_dirサポートの登場により、少し簡単になりましたpostgresql.conf。これで、1行追加するだけで、残りすべての生成された構成ファイルを書き込むことができます。

PostgreSQLを使用したより高速なテスト

テスト目的でPostgreSQLのパフォーマンスを安全に改善する方法の詳細については、このトピックで以前に書いた詳細な回答を参照してください：高速テストのためのPostgreSQLの最適化

H2のPostgreSQL方言は真の代用ではありません

代わりに、PostgreSQL方言モードでH2データベースを使用してテストを実行する人もいます。これは、テストにSQLiteを使用し、本番環境にPostgreSQLを使用しているRailsの人々と同じくらい悪いと思います。

H2はいくつかのPostgreSQL拡張機能をサポートし、PostgreSQL方言をエミュレートします。ただし、それだけです-エミュレーション。H2がクエリを受け入れるがPostgreSQLは受け入れない、動作が異なるなどの領域があります。また、執筆時点で、ウィンドウ関数のように、PostgreSQLがH2だけでは実行できない処理をサポートしている場所もたくさんあります。

このアプローチの制限を理解していて、データベースへのアクセスが簡単であれば、H2は大丈夫かもしれません。しかしその場合は、とにかく興味深い機能を使用していないため、データベースを抽象化するORMのより良い候補となるでしょう。その場合、データベースの互換性を気にする必要はありません。

テーブルスペースは答えではありません！

「インメモリ」データベースの作成にテーブルスペースを使用しないでください。とにかくパフォーマンスを大幅に向上させることができないので、それは不必要であるだけでなく、同じPostgreSQLインストールで気になる可能性のある他のすべてへのアクセスを中断する優れた方法でもあります。9.4ドキュメントには、次の警告が含まれています。

警告

メインのPostgreSQLデータディレクトリの外にある場合でも、テーブルスペースはデータベースクラスターの不可欠な部分であり、データファイルの自律的なコレクションとして扱うことはできません。これらはメインデータディレクトリに含まれるメタデータに依存しているため、別のデータベースクラスターにアタッチしたり、個別にバックアップしたりすることはできません。同様に、テーブルスペースを失うと（ファイルの削除、ディスク障害など）、データベースクラスターが読み取り不能になるか、起動できなくなる可能性があります。ramdiskのような一時ファイルシステムにテーブルスペースを配置すると、クラスター全体の信頼性が低下します。

あまりにも多くの人がこれをやっていて、トラブルに遭遇していることに気づいたからです。

（これを行った場合mkdir、不足しているテーブルスペースディレクトリを使用してPostgreSQLを再起動できますDROP。不足しているデータベースやテーブルなどがあります。実行しない方がよいでしょう。）

または、ramfs / tempfsにTABLESPACEを作成し、そこにすべてのオブジェクトを作成することもできます。
私は最近、Linuxでそれを正確に行うことについての記事を指摘されました。

警告

これにより、データベースクラスタ全体の整合性が損なわれる可能性があります。
マニュアルに追加された警告を読んでください。
したがって、これは消費可能なデータのオプションにすぎません。

以下のためにユニットテストのそれはうまく動作するはずです。同じマシンで他のデータベースを実行している場合は、安全を確保するために、別のデータベースクラスター（独自のポートを持つ）を使用してください。

OpenTableの埋め込みPostgreSQLコンポーネント（https://github.com/opentable/otj-pg-embedded）を介して、JUnitテストでPostgreSQLのメモリ内インスタンスを実行できるようになりました。

依存関係をotj-pg-embeddedライブラリ（https://mvnrepository.com/artifact/com.opentable.components/otj-pg-embedded）に追加することにより、PostgreSQLの独自のインスタンスを@Beforeおよび@Aferフック：

EmbeddedPostgres pg = EmbeddedPostgres.start();

これらは、JUnitが自動的にPostgreSQLデータベースサーバーを起動および停止するJUnitルールを提供します。

@Rule
public SingleInstancePostgresRule pg = EmbeddedPostgresRules.singleInstance();

TestContainersを使用して、テスト用のPosgreSQL Dockerコンテナーを起動できます：http ://testcontainers.viewdocs.io/testcontainers-java/usage/database_containers/

TestContainersはJUnit @ Rule / @ ClassRuleを提供します。このモードは、テストの前にコンテナー内のデータベースを開始し、後でそれを破棄します。

例：

public class SimplePostgreSQLTest {

    @Rule
    public PostgreSQLContainer postgres = new PostgreSQLContainer();

    @Test
    public void testSimple() throws SQLException {
        HikariConfig hikariConfig = new HikariConfig();
        hikariConfig.setJdbcUrl(postgres.getJdbcUrl());
        hikariConfig.setUsername(postgres.getUsername());
        hikariConfig.setPassword(postgres.getPassword());

        HikariDataSource ds = new HikariDataSource(hikariConfig);
        Statement statement = ds.getConnection().createStatement();
        statement.execute("SELECT 1");
        ResultSet resultSet = statement.getResultSet();

        resultSet.next();
        int resultSetInt = resultSet.getInt(1);
        assertEquals("A basic SELECT query succeeds", 1, resultSetInt);
    }
}

Yandexという名前のロシアの検索会社からのPostgreSQLのインメモリバージョンがあります：https : //github.com/yandex-qatools/postgresql-embedded

Flapdoodle OSSの埋め込みプロセスに基づいています。

使用例（githubページから）：

// starting Postgres
final EmbeddedPostgres postgres = new EmbeddedPostgres(V9_6);
// predefined data directory
// final EmbeddedPostgres postgres = new EmbeddedPostgres(V9_6, "/path/to/predefined/data/directory");
final String url = postgres.start("localhost", 5432, "dbName", "userName", "password");

// connecting to a running Postgres and feeding up the database
final Connection conn = DriverManager.getConnection(url);
conn.createStatement().execute("CREATE TABLE films (code char(5));");

しばらく使っています。それはうまくいきます。

更新：このプロジェクトはもはや積極的に維持されていません

Please be adviced that the main maintainer of this project has successfuly 
migrated to the use of Test Containers project. This is the best possible 
alternative nowadays.

また、PostgreSQLの構成設定（質問やここで受け付ける回答など）を使用して、インメモリデータベースに頼ることなくパフォーマンスを実現することもできます。

NodeJSを使用している場合、pg-mem（免責事項：私は作成者です）を使用して、postgres dbの最も一般的な機能をエミュレートできます。

PGの動作をレプリケートする完全なインメモリの分離された、プラットフォームにとらわれないデータベースがあります（ブラウザでも実行されます）。

単体テストでの使用方法を示す記事をここに書きました。