Tests de contrat pilotés par le consommateur : vérifier des intégrations sans environnement partagé

Ce que c'est

Un test de contrat vérifie que les deux parties d'une intégration s'accordent sur la forme de leur échange sans exécuter les deux ensemble. Dans la variante pilotée par le consommateur, le consommateur — que la documentation de Pact définit comme la partie qui initie la requête ou lit le message — rédige le contrat : chaque interaction enregistre une requête attendue et une réponse minimale attendue, à savoir les parties de la réponse que le consommateur utilise réellement. Le test du consommateur s'exécute par rapport à un fournisseur simulé (mock) généré à partir de cette description, et le résultat est un fichier de pacte (pact file). La vérification côté fournisseur rejoue chaque requête par rapport au fournisseur réel et réussit si la réponse contient au moins les données décrites. Les états du fournisseur (« l'utilisateur 123 existe ») établissent des préconditions au lieu d'enchaîner des appels. Le bliki de Fowler décrit la forme générale : les tests de contrat confirment qu'un double de test correspond toujours au service réel, et ils s'exécutent au rythme des changements du service externe plutôt qu'à celui du pipeline du consommateur.

Pourquoi c'est important

Les environnements qui démarrent chaque service détectent les changements cassants tardivement, sont partagés, et échouent pour des raisons sans rapport avec le changement testé. Les tests de contrat déplacent la détection dans l'exécution des tests unitaires propres à chaque service, et rendent le couplage explicite : un fournisseur peut voir quels champs les consommateurs utilisent et lesquels sont libres de changer. Le Pact Broker enregistre quelles versions de consommateur et de fournisseur ont été vérifiées l'une par rapport à l'autre ; la commande can-i-deploy vérifie une version par rapport aux versions enregistrées comme déployées dans un environnement, et se termine avec un code non nul lorsqu'une vérification manque ou a échoué.

Comment l'appliquer

• Générer les interactions à partir du code client réel du consommateur ; ne décrire que les champs que le consommateur lit, et utiliser des sélecteurs de type (type matchers) lorsque la valeur exacte n'est pas le sujet.
• Garder les interactions indépendantes ; exprimer les préconditions sous forme d'états du fournisseur, jamais sous forme d'une séquence d'appels.
• Publier les pactes depuis le pipeline du consommateur, les vérifier dans le pipeline du fournisseur, enregistrer les déploiements, et conditionner les mises en production à la vérification de compatibilité plutôt qu'à une exécution partagée en préproduction.
• Traiter une vérification échouée comme le début d'une discussion : soit le changement du fournisseur casse un consommateur, soit l'attente du consommateur était plus stricte que nécessaire.

Pièges

Un contrat qui copie l'intégralité de la réponse du fournisseur constitue une seconde copie de l'API et casse à chaque changement. Les tests de contrat vérifient la forme et la sémantique convenue, pas les règles métier, la performance ou l'autorisation. Le contrat n'est honnête que dans la mesure où le consommateur l'est sur ce qu'il utilise réellement. Sans courtier (broker) ou registre équivalent des versions vérifiées, la matrice se perd et les équipes reviennent à « tout exécuter ensemble ». Les intégrations fondées sur des messages ont besoin de la même discipline : le pacte décrit alors le message minimal que le consommateur peut traiter.