Contract testing vérifie que deux services s'accordent sur leur API sans les exécuter ensemble dans un test d'intégration complet. Dans les consumer-driven contracts (CDC), le consommateur définit ce dont il a besoin, et le fournisseur vérifie qu'il peut le livrer.
Les tests end-to-end complets sur de nombreux services sont lents, instables et difficiles à exécuter à chaque commit. Les contract tests détectent les changements d'API cassants tôt, en isolation.
1. Consumer writes expectations ─▶ generates a CONTRACT (Pact file)
2. Contract published to a broker
3. Provider runs the contract against itself in its own pipeline
4. Provider build FAILS if it would break the consumer
// consumer declares exactly what it expects from the provider
provider.given('order 42 exists')
.uponReceiving('a request for order 42')
.withRequest({ method: 'GET', path: '/orders/42' })
.willRespondWith({
status: 200,
body: { id: '42', total: 99.5 } // the shape the consumer relies on
});
Le CI du fournisseur rejoue ceci et échoue s'il ne retourne plus cette structure.
| Contract test | Integration test | |
|---|---|---|
| Services exécutés | Un à la fois | Tous ensemble |
| Vitesse | Rapide | Lent |
| Détecte | Ruptures de contrat | Problèmes de câblage réels |
Les contract tests vous donnent la confiance qu'un changement du fournisseur ne cassera pas les consommateurs, sans le coût et l'instabilité de démarrer l'ensemble du système.
Ils rendent le déploiement indépendant sûr : le pipeline de chaque équipe sait immédiatement si son changement violerait un contrat sur lequel quelqu'un dépend.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don