Pourquoi les tests d'intégration d'API ont besoin d'un graphe explicite
| L'ordre devient accidentel | Les tests passent dans l'ordre que le runner a choisi par hasard, puis échouent sur une autre machine. Quelqu'un ajoute un plugin de tri et le problème s'installe définitivement. |
| Un échec ressemble à vingt échecs | L'appel de création échoue, tout ce qui en dépend échoue, et vous obtenez un écran rouge. Retrouver le premier échec réel devient le vrai travail. |
| Le parallélisme n'est pas sûr | Sans savoir ce qui dépend de quoi, vous ne pouvez rien exécuter en parallèle sans risque. Les suites restent donc séquentielles et lentes. |
Le rendre explicite
La solution : que chaque test déclare ce dont il a besoin et ce qu'il produit. Une fois cette information disponible, le runner en déduit un ordre d'exécution sûr, les branches indépendantes s'exécutent en parallèle, et un échec marque ses dépendants comme ignorés plutôt qu'en échec. Vingt lignes rouges deviennent un échec et dix-neuf tests ignorés, ce qui change complètement l'expérience de débogage.
C'est toute la différence entre les Endpoint Tests, qui couvrent une route à la fois, et les Integration Tests, qui sont des chaînes en plusieurs étapes où une réponse alimente la suivante.
Le problème du passage de valeurs
Un appel de création renvoie un identifiant dont les étapes suivantes ont besoin. Codez-le en dur et le test fonctionne exactement une fois. Capturez-le et la chaîne transmet correctement les données. Écrit noir sur blanc, cela paraît trivial, et c'est pourtant la raison la plus fréquente pour qu'une suite qui passait le mois dernier échoue aujourd'hui.
Le nettoyage dans une chaîne
Les tests d'intégration créent plus d'état que les tests sur un seul endpoint, et ils le créent selon un ordre de dépendances que le teardown doit respecter. Vous ne pouvez pas supprimer le client avant la commande. Un nettoyage rattaché à ce que l'exécution a créé, dans l'ordre inverse des dépendances, est la seule version qui survit à la concurrence.
Quatre éléments déterminent si une suite d'API survit à sa première année : les sessions qui expirent, les valeurs qui n'existent qu'à l'exécution, les appels qui dépendent les uns des autres et les enregistrements que personne ne nettoie. TestSprite les traite avec Auto-Authentication, Dynamic Variables, Dependency Chains et Auto-Cleanup, décrits dans la documentation sur les tests d'API.
Que faire quand une chaîne échoue à l'étape quatre
C'est dans l'allure d'un échec que l'intérêt de déclarer les dépendances apparaît le plus clairement, et il vaut la peine d'en connaître l'ordre de lecture.
D'abord, vérifiez si l'échec vient de l'étape elle-même ou de ses entrées. Une étape qui a reçu le mauvais identifiant a échoué parce que quelque chose en amont a produit la mauvaise valeur : corriger l'étape reviendrait à corriger le symptôme.
Ensuite, vérifiez si l'échec se produit aussi à partir d'un état propre. Une chaîne qui fonctionne une fois et échoue à la réexécution vous dit que le nettoyage n'a pas eu lieu : c'est un bug différent de celui que vous cherchez, et souvent le plus important des deux.
Enfin, seulement à ce moment-là, regardez l'endpoint lui-même. La plupart du temps, l'information intéressante se trouvait dans les deux premières vérifications : c'est pourquoi une liste plate de lignes rouges coûte bien plus cher à déboguer qu'un graphe avec un échec et dix-neuf tests ignorés.
Gardez des chaînes courtes
Une chaîne de douze étapes qui échoue à la neuvième est difficile à diagnostiquer et lente à relancer. Trois à cinq étapes couvrant une seule intention utilisateur, c'est la taille qui reste utile. Les chaînes longues signifient généralement que deux parcours ont été fusionnés.
Pour commencer
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Si vous préférez ne rien installer, le tableau de bord fait la même chose. Tout ce que la ligne de commande sait faire par ailleurs se trouve dans le dépôt du CLI.
Connectez le dépôt depuis le tableau de bord et les exécutions démarrent à partir du déploiement que vous produisez déjà, ou ajoutez plutôt une étape à votre propre workflow.
Comment TestSprite rend le graphe explicite
Chaque cas déclare ce dont il a besoin et ce qu'il produit, et Dependency Chains en déduit un ordre d'exécution sûr. Les branches indépendantes s'exécutent en parallèle et, quand quelque chose échoue, ses dépendants sont marqués comme ignorés plutôt qu'en échec : vingt lignes rouges deviennent un échec et dix-neuf tests ignorés.
Dynamic Variables prend en charge le passage des valeurs : une chaîne transporte l'identifiant renvoyé par l'appel de création plutôt qu'un nombre collé à la main. Auto-Cleanup supprime ce que chaque exécution a créé, dans l'ordre inverse des dépendances, ce qui rend les exécutions concurrentes sûres.
Le bénéfice apparaît dès la première fois qu'une chaîne casse. Vous obtenez un échec unique qui désigne la divergence au lieu d'un écran rouge à éplucher : c'est la différence entre un diagnostic de cinq minutes et un après-midi.
En quoi est-ce différent des tests de bout en bout ?
Le bout en bout passe généralement par l'interface. Les tests d'intégration d'API parcourent les mêmes trajets au niveau de la couche service, ce qui est plus rapide et plus précis sur l'endroit où l'échec s'est produit.
Les tests d'intégration doivent-ils utiliser de vraies dépendances ?
Pour des tests d'intégration, oui : c'est tout l'objet. Mocker ce avec quoi vous vous intégrez répond à une autre question.
Comment gérer les données de test entre les étapes ?
Capturez ce que chaque étape produit et transmettez-le à la suivante. Les jeux de données préchargés partagés sont pratiques, jusqu'au jour où deux chaînes touchent au même enregistrement.
Et les services tiers dans une chaîne ?
Utilisez leur sandbox quand il en existe une. Quand il n'y en a pas, isolez cette étape et acceptez que la chaîne ait une frontière.
De combien de tests d'intégration avons-nous besoin ?
Un par parcours utilisateur qui compte, pas un par combinaison d'endpoints. Les combinaisons sont infinies, les parcours non.
Déclarez le graphe, ou déboguez-le indéfiniment.
Les tests d'intégration d'API portent sur des séquences, et les séquences ont un graphe de dépendances. Déclarer ce dont chaque test a besoin et ce qu'il produit vous donne un ordre d'exécution sûr, du parallélisme et des échecs lisibles. Capturez les valeurs au lieu de les coder en dur, et gardez les chaînes courtes.