# 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](stores.md)).

## 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.