Bases de données éphémères en conteneurs pour les tests d'intégration

Objectif

Exécuter les tests d'accès aux données et d'intégration contre le véritable moteur de base de données, démarré à neuf pour l'exécution, afin que les tests détectent les comportements de dialecte, de contraintes et de transactions qu'un substitut en mémoire ou un dépôt simulé (mock) dissimule.

Prérequis

Un runtime de conteneurs sur les machines de développement et en intégration continue (CI) ; des migrations applicables depuis zéro par une seule commande ; des tests qui lisent les paramètres de connexion depuis la configuration plutôt que de supposer un port fixe ou une base de données existante.

Étapes

1. Démarrer le moteur une fois par exécution de tests, pas par test. Testcontainers se présente comme fournissant des instances légères et jetables de bases de données dans des conteneurs Docker, démarrées depuis le code de test puis supprimées ensuite ; l'alternative simple est docker run avec un port publié aléatoire relu depuis le runtime.
2. Placer le répertoire de données sur un montage tmpfs (--tmpfs avec docker run) et assouplir les paramètres de durabilité du moteur pour un usage non productif, puisque les données sont jetables.
3. Appliquer les migrations une seule fois sur une base de données modèle. La documentation PostgreSQL indique que CREATE DATABASE fonctionne en copiant une base de données existante, si bien que CREATE DATABASE t_42 TEMPLATE t_base fournit à chaque fichier de test une copie fraîche sans réexécuter les migrations. La base source ne doit avoir aucune autre connexion pendant sa copie.
4. Choisir une seule stratégie d'isolation et l'appliquer partout : une base de données fraîche par fichier de test, une transaction par test annulée (rollback) ensuite, ou la troncature des tables touchées par un test.
5. Générer les paramètres de connexion à partir du conteneur en cours d'exécution et les transmettre par le même chemin de configuration que celui utilisé par l'application en production, afin que le test couvre aussi la gestion de la configuration.
6. Épingler le tag de l'image à la version majeure de production et utiliser une configuration identique en local et en intégration continue.

Résultat attendu

Les tests sollicitent le véritable planificateur de requêtes, les contraintes, les niveaux d'isolation et les fonctions d'extension ; une exécution réussie signifie que le schéma et les requêtes concordent, et une migration qui casse une requête échoue avant le déploiement.

Limites et base de vérification

Le démarrage ajoute des secondes à chaque exécution, il faut donc garder les tests unitaires purs dans une suite séparée et plus rapide. Testcontainers documente la réutilisation d'un conteneur entre exécutions comme une fonctionnalité expérimentale à activer explicitement, non adaptée à un usage en intégration continue. Une transaction annulée (rollback) ne peut pas tester du code qui valide (commit), utilise plusieurs connexions ou s'appuie sur des déclencheurs (triggers) qui se déclenchent au commit. Une base de données cloud managée peut différer de l'image par ses extensions et ses paramètres ; cette méthode teste le moteur, pas le service managé. Aucun chiffrage de durée n'est avancé.