Meilleures pratiques de simulation de dépendances qui garantissent la fiabilité des tests d’intégration

Introduction

Les tests d’intégration qui étaient fiables le mois dernier ne le sont pas automatiquement ce mois-ci.

Les services en amont dont dépendent ces tests ont été déployés. Le service de paiement a expédié une nouvelle version. Le service d’inventaire a mis à jour son schéma de réponse. Le service de notification a modifié la façon dont il gère certaines conditions d’erreur. Aucun de ces changements n’a été notifié à la suite de tests de l’équipe en aval. Les simulations utilisées par ces tests renvoient toujours ce pour quoi ils ont été configurés lors de leur écriture.

C’est le problème de la moquerie des dépendances que les meilleures pratiques doivent résoudre. Pas la configuration initiale – la précision continue.

Écrivez des moqueries sur ce que le service renvoie, pas sur ce que disent les documents

La documentation de l’API décrit l’intention. Le service en cours reflète la réalité. Ces deux choses ne sont pas toujours identiques, et lorsqu’elles divergent, une simulation écrite à partir de la documentation code l’intention tandis que le service réel reflète la réalité.

La conséquence pratique : une simulation écrite à partir de documents peut manquer des champs inclus dans le service réel, renvoyer des formats d’erreur que le service réel n’utilise plus ou omettre des en-têtes de réponse qui affectent la façon dont l’application traite la réponse. Les tests réussissent avec cette simulation car celle-ci est cohérente en interne. L’application atteint le service réel en production et se comporte différemment de ce que prédisaient les tests.

Envoyez une véritable demande au service de mise en scène avant d’écrire une simulation. Regardez la réponse réelle. Construisez la simulation à partir de ce que le service renvoie. La documentation vous indique ce que quelqu’un voulait que le service fasse. Le service de mise en scène vous indique ce qu’il fait. Pour les équipes dont les API internes se mettent à jour plus rapidement que leur documentation, cette distinction évite toute une catégorie de fausse confiance.

Affirmez-vous sur les champs utilisés par l’application, rien de plus

Une simulation qui couvre chaque champ d’une réponse crée des tests qui s’interrompent chaque fois qu’un champ change, y compris les champs que l’application ne lit pas ou ne s’intéresse pas.

Un service en amont ajoute un nouveau champ facultatif à sa réponse de réussite. La maquette ne l’inclut pas. L’assertion échoue car la réponse réelle d’un véritable appel de service l’inclut. Le code de l’application ne touche jamais ce champ. Rien dans le comportement de l’application n’a changé. Mais le test échoue quand même – et le développeur qui le corrige met à jour la simulation, exécute à nouveau le test et continue sans savoir si le changement qu’il vient d’apporter était significatif ou non.

Écrire des assertions plus étroites est la solution contre-intuitive. Identifiez les champs que l’application lit et traite activement. Si le service de commande lit « charge.status », « charge.amount » et « charge.payment_method_details.type » dans la réponse du service de paiement, affirmez ces trois éléments. Laissez le reste sans affirmation. Le mois prochain, lorsque le service de paiement ajoute un nouveau champ, le test tient. Lorsqu’il modifie un champ ignoré par le service de commande, le test est maintenu. Lorsqu’il modifie l’un de ces trois champs, le test s’interrompt exactement au moment où il le devrait.

Séparer les champs déterministes des champs variables

Chaque véritable réponse API contient des champs qui changent à chaque appel. Identifiants générés, horodatages, ID de corrélation de demande, jetons de session. Les inclure textuellement dans une simulation, puis les affirmer, produit des échecs sans rapport avec le bon fonctionnement de l’application : les valeurs ne correspondront jamais lors des différentes exécutions de tests.

La plupart des équipes découvrent cela à leurs dépens, après avoir écrit plusieurs simulations et les avoir vues échouer par intermittence. L’identification des champs variables avant d’écrire le mock élimine ce problème dès le départ. Faites la même demande au service de transfert plusieurs fois et comparez les réponses côte à côte.

Les champs produisant des valeurs différentes selon les appels sont variables et appartiennent en dehors de l’ensemble d’assertions. Les champs produisant des valeurs identiques sont stables et peuvent être affirmés directement. Sauter cette comparaison signifie deviner, et se tromper signifie des échecs intermittents ou des affirmations trop vagues pour détecter de vrais problèmes.

Documenter la date à laquelle chaque maquette a été validée pour la dernière fois

Une simulation sans métadonnées est un handicap. L’équipe ne sait pas quand il a été écrit, sur quelle version du service en amont il a été validé, ni combien de déploiements en amont ont eu lieu depuis la dernière confirmation de son exactitude.

Une simulation avec une date de validation et une référence à la version du service en amont avec laquelle elle a été capturée est un risque sur lequel l’équipe peut raisonner. Le service est déployé chaque semaine et la simulation a été validée il y a trois mois – c’est une information significative avant une sortie. Sans cela, l’équipe n’a aucune base pour donner la priorité à une révision simulée, sauf en attendant un échec de test ou un incident de production pour identifier celui qui est périmé.

L’ajout de ces métadonnées à des fichiers fictifs ne coûte presque rien. Sa lecture avant un déploiement révèle quelles simulations comportent le plus de risques de dérive. Les simulations les plus susceptibles d’être devenues inexactes sont celles validées il y a le plus longtemps sur les services qui ont été déployés le plus de fois depuis – et sans les métadonnées, il n’y a aucun moyen de les identifier jusqu’à ce que quelque chose se brise.

Connecter l’actualisation simulée aux événements de déploiement en amont

L’approche standard de la maintenance simulée est réactive. Un incident de production ou un échec de test révèle qu’une simulation ne reflète plus le comportement actuel en amont. La maquette est mise à jour. L’équipe avance jusqu’à ce que le prochain incident ou échec révèle la prochaine simulation périmée.

Le problème de cette approche est son déclencheur. Il faut que quelque chose se brise visiblement avant que la maintenance n’ait lieu. Dans une suite de tests où les simulations sont obsolètes mais où les tests réussissent quand même – parce que les assertions s’appuient sur les hypothèses comportementales obsolètes de la simulation plutôt que sur le comportement réel actuel – le déclencheur n’arrive jamais. La maquette ne cesse d’accumuler de la dérive. Le test continue de réussir. Le déploiement en production rencontre le service réel et s’interrompt.

Le meilleur déclencheur réside dans les événements de déploiement en amont plutôt que dans les échecs en aval. Lorsque le service de paiement est déployé en phase intermédiaire, c’est le moment de vérifier que les simulations représentant le service de paiement reflètent toujours le comportement actuel du service de paiement. Pas après le prochain incident de production. Pas selon un horaire hebdomadaire qui peut ou non correspondre à la cadence de déploiement réelle. Lors de l’événement de déploiement, avant que le service en aval n’expédie du code qui dépend d’hypothèses comportementales, le service en amont vient peut-être d’invalider.

La connexion de l’actualisation simulée aux événements de déploiement en amont nécessite de savoir quand les services en amont se déploient et de disposer d’un processus qui s’exécute en réponse. Les équipes qui mettent en œuvre cela – que ce soit via des intégrations de webhooks CI/CD, des abonnements aux notifications de déploiement ou des déclencheurs de pipeline partagés – découvrent systématiquement une dérive comportementale lors de l’événement de déploiement en amont plutôt que lors de l’incident de production en aval.

Gardez une simulation par scénario, pas une simulation par test

Une suite de tests dans laquelle chaque test possède sa propre configuration simulée complète accumule des duplications qui rendent la maintenance exponentiellement plus difficile.

La simulation de réussite du service de paiement est copiée dans quinze fichiers de test différents, car quinze tests différents nécessitent un service de paiement pour renvoyer une réponse réussie. Lorsque le service de paiement modifie son format de réponse de réussite, les quinze simulations doivent être mises à jour. L’équipe qui en met à jour un ne met pas toujours à jour les quinze. Les quatorze restants deviennent périmés. Onze d’entre eux réussissent quand même leurs tests parce que leurs assertions ne touchent pas aux champs modifiés. Trois d’entre eux se cassent. L’équipe corrige ces trois-là. Les onze avec des affirmations périmées continuent de passer jusqu’à ce que le prochain changement crée un échec différent.

La centralisation des configurations fictives par scénario élimine ce modèle. Une simulation du scénario de réussite du service de paiement, partagée entre tous les tests qui en ont besoin. Une simulation pour le scénario de refus du service de paiement. Une simulation pour chaque condition d’erreur. Lorsque l’un de ces changements est mis à jour en un seul endroit, il est mis à jour partout : la charge de maintenance augmente avec le nombre de scénarios distincts, et non avec le nombre de tests.

Valider les simulations par rapport à la mise en scène avant chaque version

Le moment le plus coûteux pour découvrir une maquette obsolète est après un déploiement en production. Le moment le moins coûteux se situe avant un déploiement intermédiaire, lorsque la modification peut être annulée ou que la simulation peut être mise à jour sans aucun impact sur l’utilisateur.

Une passe de validation fictive de pré-version exécute les configurations fictives sur les services de test réels et vérifie si les réponses renvoyées par les simulacres correspondent toujours à ce que renvoient les services réels – toute divergence fait surface avant la publication.

Cela ne nécessite pas d’outillage élaboré. Un script qui appelle chaque point de terminaison intermédiaire avec la même requête que la simulation représente et compare la structure de réponse réelle à la structure de réponse fictive détecte la dérive structurelle avant qu’elle n’atteigne la production.

Automatisez cette couche de validation en capturant le trafic HTTP réel entre les services au niveau du noyau via eBPF pendant les sessions d’enregistrement dans des environnements de test. Plutôt que d’écrire ou de mettre à jour manuellement des structures de réponse fictives, la session d’enregistrement observe ce que le service réel renvoie et génère des configurations fictives à partir de ces observations.

La comparaison entre la configuration fictive précédente et le nouvel enregistrement fait apparaître explicitement des changements de comportement (champs ajoutés, champs supprimés, types modifiés), ce qui donne à l’équipe les informations nécessaires pour décider si le changement nécessite des mises à jour du code d’application avant de procéder à la publication.

Pour les équipes dont les services en amont se déploient fréquemment selon des calendriers indépendants, cette approche basée sur l’observation transforme la maintenance fictive d’une tâche réactive déclenchée par des pannes en un processus proactif déclenché par des événements de déploiement en amont.

La métrique qui révèle la qualité simulée

Le pourcentage de couverture ne révèle pas une qualité simulée. Une suite de tests avec une couverture élevée peut avoir des simulations profondément obsolètes qui sont toutes réussies parce que leurs assertions ont été conçues à l’encontre du comportement historique que les services en amont ont depuis dépassé.

La mesure qui révèle la qualité fictive est celle des échecs de production liés au comportement d’intégration que la suite de tests prétend couvrir. Un échec d’intégration des paiements en production survenu malgré une simulation de service de paiement dans la suite de tests ne constitue pas une lacune de couverture. Il s’agit d’un écart de précision simulé. Le test existait. La simulation était fausse. Le test a réussi. La production a échoué.

Les équipes qui suivent cette mesure séparément de la couverture – en distinguant entre « nous n’avons eu aucun test pour cela » et « nous avons eu un test, mais la simulation était périmée » – obtiennent une image beaucoup plus précise de la manière dont leur investissement dans la simulation de dépendance produit une protection fiable et de ceux où il produit une fausse confiance qui coûte plus cher que de ne pas avoir de simulation du tout.