Les tests de contrat et ce qu'ils ne vérifient volontairement pas

Ce que les tests de contrat vérifient

Que la structure attendue de part et d'autre est bien la même. Noms de champs, types, champs obligatoires et facultatifs, codes de statut. Si un producteur supprime un champ dont dépend un consommateur, les tests de contrat échouent au moment du build plutôt qu'à trois heures du matin.

Pour un système comportant de nombreux services et des déploiements indépendants, c'est réellement utile et bien moins coûteux que des environnements d'intégration de bout en bout.

Ce qu'ils ne vérifient volontairement pas

• Si la valeur est juste. Une réponse correctement structurée contenant un total erroné satisfait tous les contrats.

• Si le flux fonctionne. Chaque appel peut satisfaire son contrat alors que la séquence produit un résultat absurde.

• Ce que voit l'utilisateur. Les contrats concernent des services qui dialoguent avec des services. Personne n'a ouvert le produit.

Rien de tout cela n'est une critique. Un test de contrat qui vérifierait les valeurs serait couplé aux données et casserait sans arrêt, ce qui est précisément ce que les tests de contrat ont été conçus pour éviter. Ce périmètre restreint est justement ce qui fait leur valeur.

Le mode de défaillance à surveiller

Une équipe adopte les tests de contrat, les échecs d'intégration cessent et la confiance grimpe. Six mois plus tard, quelque chose casse en production alors que tous les tests de contrat passaient, parce que la structure était bonne et le comportement mauvais. La leçon qu'on en tire généralement est que les tests de contrat ont échoué, et c'est la mauvaise leçon.

Les tests de contrat ont fait leur travail. La lacune, c'était que rien ne vérifiait le comportement, et le succès de la couche contractuelle rendait cette lacune d'autant plus difficile à voir.

Ce qui doit les accompagner

Une vérification fonctionnelle sur les services en cours d'exécution : la séquence d'appels produit-elle le bon résultat, les chemins d'erreur se comportent-ils correctement, l'autorisation tient-elle. C'est une autre couche, et elle répond aux questions que les contrats ne peuvent pas trancher.

Ces vérifications doivent gérer les sessions, les valeurs capturées entre les appels, l'ordonnancement et le nettoyage, autant de points traités dans la documentation sur les tests d'API.

Si vous préférez ne rien installer, le tableau de bord fait la même chose. Tout le reste de ce que la ligne de commande sait faire se trouve dans le dépôt CLI.

Les contrats pilotés par le consommateur, et pourquoi ils l'emportent le plus souvent

Les deux approches diffèrent par qui écrit le contrat, et la différence se révèle un an plus tard plutôt qu'immédiatement.

Les contrats pilotés par le producteur décrivent ce que le service entend offrir. C'est utile, et cela tend à être généreux : le contrat décrit la réponse complète, y compris des champs que personne ne consomme. Les changements cassants sur des champs inutilisés font alors échouer le build, et les équipes se mettent à ignorer les échecs de contrat, ce qui ruine l'objectif.

Les contrats pilotés par le consommateur décrivent ce que chaque consommateur lit réellement. Le contrat est plus petit, les échecs sont réels, et vous obtenez un sous-produit vraiment utile : une carte précise des champs qui importent à qui. C'est cette carte qui permet à un producteur de déprécier quelque chose en confiance, ce que tout le monde voulait en réalité.

Où s'exécute chacun

Les tests de contrat au moment du build, rapides et à chaque commit, puisque tout leur intérêt est de détecter les dérives de structure avant l'intégration. La vérification comportementale sur un environnement déployé, à chaque pull request.

Le déclencheur compte plus que le mécanisme. Le brancher sur votre événement de déploiement signifie que chaque changement est vérifié sans que personne n'ait à en décider ; la GitHub App le fait depuis le tableau de bord, et une étape GitHub Actions le fait depuis l'intérieur de votre workflow.

Ce que TestSprite répond là où les contrats ne peuvent pas

Si les valeurs sont justes et si la séquence produit le bon résultat. Il sollicite les services en cours d'exécution à travers leurs interfaces, de sorte qu'une réponse qui satisfait tous les contrats tout en contenant un total erroné est détectée.

Les flux multi-étapes sont précisément là où se situe la lacune. Integration Tests enchaîne des appels où une réponse alimente la suivante, et Dependency Chains déduit un ordre sûr de ce dont chaque cas a besoin et de ce qu'il produit. Auto-Authentication maintient les sessions actives pendant toute l'exécution, Dynamic Variables transporte les valeurs entre les appels, Dependency Chains déduit l'ordre d'exécution de ce dont chaque cas a besoin et de ce qu'il produit, et Auto-Cleanup supprime exactement ce que l'exécution a créé.

Vous obtenez au final deux couches qui ne se recouvrent pas : les contrats qui détectent les dérives de structure au moment du build, à faible coût et à chaque commit, et la vérification comportementale qui traite les questions de justesse auxquelles les contrats sont volontairement aveugles.