The test database

Each test gets its own database at the latest migration, empty except for what its fixtures create. You write nothing for this; jadpo test does it.

Tests run on PostgreSQL, because every environment runs the same engine: PostgreSQL, unless the application declares otherwise (Stores).

Where the server comes from

jadpo test starts a disposable local PostgreSQL server for the run, from the PostgreSQL tools on your machine. To use a server of your own, in CI for example, name it in JADPO_TEST_DATABASE_URL.

A copy for each test

jadpo test builds one template database from the migrations, and copies it for each test (CREATE DATABASE … TEMPLATE). A copy takes tens of milliseconds, and lets tests run in parallel. Copies are prepared in the background while tests run.

Real commits

Each test's actions commit for real. So work that runs after a commit, such as delivering events, and the checks for concurrent changes behave as in production.

Keeping a failed test's database: --keep-failed

--keep-failed keeps a failed test's database, named in the report, and its trace. jadpo trace and the developer console can then inspect exactly what it did.