Qu'est-ce qu'un test d'intégration ?
Un test d'intégration vérifie que plusieurs composants d'un système fonctionnent correctement ensemble. Contrairement aux tests unitaires qui isolent une fonction ou une classe, les tests d'intégration testent les interactions : une API avec sa base de données, 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'intégration
Tests d'API : envoyer des requêtes HTTP à un endpoint et vérifier la réponse, incluant l'interaction avec la base de données. Tests de repository : vérifier que les requêtes SQL ou les opérations ORM fonctionnent correctement avec une vraie base de données. Tests de service : vérifier l'orchestration entre plusieurs services ou modules. Tests de contrat : vérifier que l'interface entre deux services respecte le contrat attendu (Pact, Spring Cloud Contract). Les tests de contrat sont particulièrement importants dans les architectures microservices.
Environnement de test
Les tests d'intégration nécessitent 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 données en mémoire (H2 pour Java, SQLite pour Python) sont plus rapides mais peuvent masquer des problèmes spécifiques au SGBD de production. Bonne pratique : utiliser le même SGBD qu'en production (PostgreSQL de test, pas SQLite).
Patterns et bonnes pratiques
Isolation : chaque test doit être indépendant. Reinitialiser la base entre les tests (transaction rollback ou truncate). Fixtures deterministes : utiliser des données de test previsibles (factories, fixtures). Pas de dépendances externes : mocker les API tierces (WireMock, MSW) pour éviter la fragilite et la lenteur. Tests idempotents : executables dans n'importe quel ordre, repeatable. Nommage descriptif : le nom du test doit décrire le scénario et le résultat attendu.
Intégration dans le CI/CD
Les tests d'intégration sont plus lents que les tests unitaires (secondes vs millisecondes) mais plus rapides que les tests E2E. Dans le pipeline CI : exécuter les tests unitaires d'abord (fail fast), puis les tests d'intégration. Utiliser Testcontainers ou un service Docker dans le CI (GitHub Actions services, GitLab services) pour les dépendances. Paralleliser les suites de tests quand possible. Viser une exécution totale sous 10 minutes pour maintenir un feedback rapide.