Infrastructure de test

Ces règles disent sur quoi tournent les tests d’intégration et end-to-end. La base est un vrai PostgreSQL, démarré par la suite elle-même et construit par les migrations. Chaque worker a la sienne, vidée avant chaque test. Un système tiers est simulé par des stubs générés depuis son contrat, et une sandbox vérifie chaque nuit que ce contrat tient.

En pratique

La base de la suite, mise en place une fois par run :

// src/shared/__test__/database.global-setup.ts; workers is the maxWorkers of the Vitest config
export async function setup(project: TestProject): Promise<() => Promise<void>> {
	const container = await new PostgreSqlContainer('postgres:18').withDatabase('app_template').start();

	execSync('prisma migrate deploy', { env: { ...process.env, DATABASE_URL: container.getConnectionUri() } });
	project.provide('databaseUrl', container.getConnectionUri());

	for (let worker = 1; worker <= workers; worker++) {
		await admin.$executeRawUnsafe(`CREATE DATABASE test_${worker} TEMPLATE app_template`);
	}

	return async () => {
		await container.stop();
	};
}

• Un conteneur par run, démarré par Testcontainers, la même version de PostgreSQL qu’en production (INF-01).
• Le schéma vient des migrations commitées : la base de test les teste aussi (INF-01, PER-10).
• Une copie de la base modèle par worker, vidée avant chaque test : les tests tournent en parallèle sans se voir (INF-02).
• La mise en place est commune à tous les bounded contexts, dans src/shared/__test__/ (TST-05).
• Le serveur de stubs des systèmes tiers démarre de la même façon, dans src/shared/__test__/http.setup.ts (INF-04).

Règles

Base jetable

Code	Règle	Sévérité
INF-01	Les tests tournent sur une base jetable	mineure
INF-02	Chaque test part d’une base vide	mineure

Systèmes tiers

Code	Règle	Sévérité
INF-03	Un système tiers se simule depuis son contrat	mineure
INF-04	Un parcours critique a ses stubs écrits à la main	mineure
INF-05	Un test de contrat vérifie les champs consommés	mineure