Testcontainers : une vraie base pendant les tests

L'équipe a trois options, et les trois posent problème. Une base PostgreSQL partagée sur un serveur d'intégration : deux exécutions simultanées se marchent dessus, un test laisse une ligne derrière lui et casse le voisin, et personne n'ose la réinitialiser. Une base locale installée sur chaque poste : chacun a sa version, ses extensions et son schéma légèrement décalé, et l'arrivée d'un nouveau développeur coûte une demi-journée. Une base en mémoire type H2 : rapide, uniforme, et aveugle à tout ce qui est spécifique à PostgreSQL, comme on l'a vu dans la première leçon.

Testcontainers propose une quatrième voie : la suite de tests démarre elle-même un conteneur Docker PostgreSQL, y applique le schéma, exécute les tests, puis détruit le conteneur. La version est celle déclarée dans le code, donc identique partout. L'isolation est totale, donc l'exécution parallèle est possible. Et comme c'est un vrai PostgreSQL, jsonb, ILIKE, les index GIN et les contraintes d'exclusion se comportent exactement comme en production. Le prix à payer est réel — Docker devient une dépendance de la suite, et le démarrage coûte du temps — et la majeure partie de cette leçon porte précisément sur la manière de contenir ce prix.