mirror of
https://github.com/Unleash/unleash.git
synced 2025-02-14 00:19:16 +01:00
5e9698fe63
## About the changes
Based on the first hypothesis from
https://github.com/Unleash/unleash/pull/9264, I decided to find an
alternative way of initializing the DB, mainly trying to run migrations
only once and removing that from the actual test run.
I found in [Postgres template
databases](https://www.postgresql.org/docs/current/manage-ag-templatedbs.html)
an interesting option in combination with jest global initializer.
### Changes on how we use DBs for testing
Previously, we were relying on a single DB with multiple schemas to
isolate tests, but each schema was empty and required migrations or
custom DB initialization scripts.
With this method, we don't need to use different schema names
(apparently there's no templating for schemas), and we can use new
databases. We can also eliminate custom initialization code.
### Legacy tests
This method also highlighted some wrong assumptions in existing tests.
One example is the existence of `default` environment, that because of
being deprecated is no longer available, but because tests are creating
the expected db state manually, they were not updated to match the
existing db state.
To keep tests running green, I've added a configuration to use the
`legacy` test setup (24 tests). By migrating these, we'll speed up
tests, but the code of these tests has to be modified, so I leave this
for another PR.
## Downsides
1. The template db initialization happens at the beginning of any test,
so local development may suffer from slower unit tests. As a workaround
we could define an environment variable to disable the db migration
2. Proliferation of test dbs. In ephemeral environments, this is not a
problem, but for local development we should clean up from time to time.
There's the possibility of cleaning up test dbs using the db name as a
pattern:
2ed2e1c274/scripts/jest-setup.ts (L13-L18)
but I didn't want to add this code yet. Opinions?
## Benefits
1. It allows us migrate only once and still get the benefits of having a
well known state for tests.
3. It removes some of the custom setup for tests (which in some cases
ends up testing something not realistic)
4. It removes the need of testing migrations:
https://github.com/Unleash/unleash/blob/main/src/test/e2e/migrator.e2e.test.ts
as migrations are run at the start
5. Forces us to keep old tests up to date when we modify our database
36 lines
1.6 KiB
TypeScript
36 lines
1.6 KiB
TypeScript
import { Client, type ClientConfig } from 'pg';
|
|
import { migrateDb } from '../src/migrator';
|
|
import { getDbConfig } from '../src/test/e2e/helpers/database-config';
|
|
|
|
let initializationPromise: Promise<void> | null = null;
|
|
const initializeTemplateDb = (db: ClientConfig): Promise<void> => {
|
|
if (!initializationPromise) {
|
|
initializationPromise = (async () => {
|
|
const testDBTemplateName = process.env.TEST_DB_TEMPLATE_NAME;
|
|
const client = new Client(db);
|
|
await client.connect();
|
|
console.log(`Initializing template database ${testDBTemplateName}`);
|
|
// code to clean up, but only on next run, we could do it at tear down... but is it really needed?
|
|
// const result = await client.query(`select datname from pg_database where datname like 'unleashtestdb_%';`)
|
|
// result.rows.forEach(async (row: any) => {
|
|
// console.log(`Dropping test database ${row.datname}`);
|
|
// await client.query(`DROP DATABASE ${row.datname}`);
|
|
// });
|
|
await client.query(`DROP DATABASE IF EXISTS ${testDBTemplateName}`);
|
|
await client.query(`CREATE DATABASE ${testDBTemplateName}`);
|
|
await client.end();
|
|
await migrateDb({
|
|
db: { ...db, database: testDBTemplateName },
|
|
} as any);
|
|
console.log(`Template database ${testDBTemplateName} migrated`);
|
|
})();
|
|
}
|
|
return initializationPromise;
|
|
};
|
|
|
|
export default async function globalSetup() {
|
|
process.env.TZ = 'UTC';
|
|
process.env.TEST_DB_TEMPLATE_NAME = 'unleash_template_db';
|
|
await initializeTemplateDb(getDbConfig());
|
|
}
|