testdb

Overview ¶

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

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
mysql://…                    MySQL, a new database 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 MySQL run creates a database for each Open and drops it when the test ends, so the account in the DSN needs the CREATE and DROP privileges; raw SQL written with numbered placeholders is rewritten to "?" for it.

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 or MySQL run never passes by skipping. Tests that cannot run on one dialect say so with SQLiteOnly, PostgresOnly or MySQLOnly and a reason, so every exemption is greppable.

testdb imports the modernc.org/sqlite, pgx and MySQL 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 every dialect: modernc.org/sqlite binds $N by number, and a MySQL run rewrites them to "?".