Qu'est-ce qu'un test d'integration ?
Un test d'integration verifie que plusieurs composants d'un systeme fonctionnent correctement ensemble. Contrairement aux tests unitaires qui isolent une fonction ou une classe, les tests d'integration testent les interactions : une API avec sa base de donnees, un service avec une API externe, ou un composant UI avec son backend. Ils se situent au milieu de la pyramide des tests, entre les tests unitaires (base, rapides, nombreux) et les tests end-to-end (sommet, lents, peu nombreux).
Types de tests d'integration
Tests d'API : envoyer des requetes HTTP a un endpoint et verifier la reponse, incluant l'interaction avec la base de donnees. Tests de repository : verifier que les requetes SQL ou les operations ORM fonctionnent correctement avec une vraie base de donnees. Tests de service : verifier l'orchestration entre plusieurs services ou modules. Tests de contrat : verifier que l'interface entre deux services respecte le contrat attendu (Pact, Spring Cloud Contract). Les tests de contrat sont particulierement importants dans les architectures microservices.
Environnement de test
Les tests d'integration necessitent un environnement proche de la production. Testcontainers lance des conteneurs Docker ephemeres (PostgreSQL, Redis, Kafka) pour chaque suite de tests. Docker Compose fournit un environnement complet reproductible. Les bases de donnees en memoire (H2 pour Java, SQLite pour Python) sont plus rapides mais peuvent masquer des problemes specifiques au SGBD de production. Bonne pratique : utiliser le meme SGBD qu'en production (PostgreSQL de test, pas SQLite).
Patterns et bonnes pratiques
Isolation : chaque test doit etre independant. Reinitialiser la base entre les tests (transaction rollback ou truncate). Fixtures deterministes : utiliser des donnees de test previsibles (factories, fixtures). Pas de dependances externes : mocker les API tierces (WireMock, MSW) pour eviter la fragilite et la lenteur. Tests idempotents : executables dans n'importe quel ordre, repeatable. Nommage descriptif : le nom du test doit decrire le scenario et le resultat attendu.
Integration dans le CI/CD
Les tests d'integration sont plus lents que les tests unitaires (secondes vs millisecondes) mais plus rapides que les tests E2E. Dans le pipeline CI : executer les tests unitaires d'abord (fail fast), puis les tests d'integration. Utiliser Testcontainers ou un service Docker dans le CI (GitHub Actions services, GitLab services) pour les dependances. Paralleliser les suites de tests quand possible. Viser une execution totale sous 10 minutes pour maintenir un feedback rapide.