testdb

Overview ¶

Package testdb gives each test a fresh database for the run's Test dialect, so one test suite runs unchanged against SQLite or PostgreSQL.

The run's dialect comes from one variable, TANGO_TEST_DSN, read by its scheme through db.ParseDSN, the same grammar an app's TANGO_DB_DSN uses:

unset or sqlite://:memory:   SQLite, in memory
sqlite://<any path>          SQLite, a new file per test under t.TempDir()
postgres://… postgresql://…  PostgreSQL, a new schema per test

One scheme-qualified variable, rather than a dialect variable beside a DSN, means the two can never disagree, and anyone who can configure an app already knows how to point its tests somewhere. The SQLite file path only selects file-backed mode; it is never opened, because a file shared between tests would leak rows from one into the next.

A PostgreSQL run gets a schema created for each Open, set as every connection's search_path and dropped with CASCADE when the test ends, so tests may commit, run DDL and run in parallel without seeing each other. An unreachable server or a malformed DSN fails the test: a PostgreSQL run never passes by skipping. Tests that cannot run on one dialect say so with SQLiteOnly or PostgresOnly and a reason, so every exemption is greppable.

testdb imports the modernc.org/sqlite and pgx drivers itself, so tests need no driver imports of their own.

Raw SQL in a test can use PostgreSQL's numbered placeholders ($1, $2, …) and TRUE/FALSE on either dialect: modernc.org/sqlite binds $N by number.