Contract testing (test de contrat)

Le contract testing (test de contrat) vérifie l’accord entre deux services de manière isolée. Chaque côté est testé par rapport à une description partagée des interactions, le contrat, au lieu de l’être contre l’autre service en fonctionnement. Si le fournisseur renomme un champ dont un consommateur dépend, un test de contrat échoue dans le pipeline du fournisseur lui-même, avant tout déploiement. En coût comme en niveau de confiance, il se situe entre les tests d’intégration et les tests end-to-end.

Comment fonctionne le contract testing piloté par le consommateur

La forme la plus courante, popularisée par l’outil Pact, est pilotée par le consommateur (consumer-driven) :

1. Le consommateur écrit un test contre un fournisseur simulé (mock), en indiquant les requêtes qu’il envoie et les parties de la réponse qu’il utilise réellement. Par exemple : GET /orders/42 renvoie 200 avec un nombre id et une chaîne status.
2. L’exécution de ce test produit un fichier de contrat (un « pact ») qui enregistre ces interactions.
3. Le contrat est partagé, généralement via un service de broker.
4. Le fournisseur vérifie le contrat en rejouant chaque requête enregistrée contre sa véritable implémentation et en contrôlant que les réponses correspondent.
5. Avant de déployer, une équipe vérifie que la version qu’elle s’apprête à livrer est compatible avec les versions de l’autre côté déjà présentes dans cet environnement.

Comme le consommateur ne liste que les champs qu’il utilise, le fournisseur reste libre d’ajouter des champs ou de modifier tout ce dont aucun consommateur ne dépend.

Différence avec les vérifications voisines

• La validation de schéma contrôle une réponse par rapport au schéma publié par le fournisseur. Elle vous dit que le fournisseur est cohérent avec sa propre documentation, pas qu’il répond toujours aux besoins de chaque consommateur.
• Les tests d’intégration appellent le vrai fournisseur. Ils nécessitent que les deux services et leurs dépendances tournent, et ils ont tendance à être plus lents et plus instables.
• Les tests end-to-end prouvent qu’un parcours complet fonctionne, mais sont un moyen lent et coûteux de découvrir qu’un champ a été renommé.

Les contrats pilotés par le fournisseur, où celui-ci publie une spécification OpenAPI contre laquelle les consommateurs testent, sont une alternative quand le fournisseur ne peut pas connaître tous ses consommateurs ni se coordonner avec eux, comme pour une API publique.

Erreurs courantes

• Trop spécifier. Vérifier des valeurs exactes ou tous les champs transforme les contrats en tests fonctionnels fragiles. Utilisez des matchers de type et n’incluez que ce que le consommateur lit.
• Tester la logique métier dans les contrats. Les contrats vérifient la forme de l’échange ; la justesse fonctionnelle relève des tests propres au fournisseur.
• Négliger les provider states. « La commande 42 existe » doit être mis en place côté fournisseur pendant la vérification, sinon la vérification échoue pour une mauvaise raison.