Tester avec une vraie base
AvancéUne base simulée ne reproduit ni les contraintes, ni les verrous, ni le SQL réel : pour le code d'accès aux données, testez avec PostgreSQL lui-même.
Testcontainers#
Une bibliothèque démarre un conteneur PostgreSQL jetable pour la durée des tests.
// .NET : Testcontainers.PostgreSql
var postgres = new PostgreSqlBuilder().WithImage("postgres:17").Build();
await postgres.StartAsync();
var connectionString = postgres.GetConnectionString();
// appliquer les migrations, puis exécuter les tests
Des équivalents existent pour Rust (testcontainers), Java, Go, Node, Python.
Isoler les tests entre eux#
| Technique | Principe | À noter |
|---|---|---|
| Transaction annulée | Chaque test ouvre une transaction et fait ROLLBACK à la fin | Très rapide ; ne teste pas les commits ni la concurrence |
| Base par test | CREATE DATABASE ... TEMPLATE modele | Isolation totale, très rapide grâce au clonage de modèle |
| Nettoyage entre tests | TRUNCATE ... RESTART IDENTITY CASCADE | Simple ; plus lent |
Que tester#
- Les migrations : appliquez-les sur une base vide et sur un instantané réaliste.
- Les contraintes : la base refuse bien le doublon ou la valeur invalide.
- Les requêtes critiques et leurs index (un test qui vérifie le plan sur un jeu de données volumineux évite bien des régressions).
- La concurrence : deux transactions simultanées sur la même ligne se comportent comme prévu.
Piège : tester contre SQLite ou une base « en mémoire » alors que la production tourne sur PostgreSQL valide un comportement qui n'existe pas (types,
RETURNING, verrous,jsonb, fuseaux) et laisse passer des bugs qui n'apparaissent qu'en production.