Les quatre niveaux des tests fonctionnels d'API
1. Statut
Le code 200 a-t-il été renvoyé.
Détecte les pannes. Passe sans broncher sur un résultat vide là où un enregistrement devrait se trouver.
2. Forme
Les champs attendus sont-ils présents, avec les types attendus.
Détecte les dérives de schéma. Ne dit rien sur la justesse des valeurs.
3. Valeur
Le total correspond-il vraiment à la somme, le statut est-il celui que cette action devrait produire.
Là où les vrais défauts commencent à être détectés.
Le quatrième est la relation: après avoir créé une commande, la consultation du client la fait-elle apparaître. Les bugs les plus intéressants vivent entre deux appels plutôt qu'à l'intérieur d'un seul, et le niveau quatre est le seul à aller y regarder.
Pourquoi les suites s'arrêtent au niveau deux
Parce que les niveaux trois et quatre exigent de savoir ce que « correct » veut dire, donc que quelqu'un tranche. Le statut et la forme se déduisent mécaniquement d'une spécification. La valeur et la relation demandent un jugement sur le produit.
C'est effectivement plus difficile, et c'est aussi là que réside tout l'intérêt. Une suite qui n'exprime jamais une règle métier vérifie de façon élaborée que le service est en ligne.
Le cas négatif que l'on néglige
Pour chaque endpoint, demandez-vous ce qui devrait être rejeté, puis vérifiez-le par une assertion. Valeurs hors plage, champs obligatoires absents, identifiant appartenant à quelqu'un d'autre. Les services qui renvoient 200 avec un objet d'erreur dans le corps sont assez répandus pour qu'une suite ignorant ce schéma reste verte indéfiniment.
Ce sur quoi repose une suite
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 prend en charge sous les noms d'Auto-Authentication, Dynamic Variables, Dependency Chains et Auto-Cleanup, décrits dans la documentation sur les tests d'API.
C'est en réglant ces points que vous pouvez consacrer votre attention aux niveaux trois et quatre plutôt qu'à l'infrastructure.
Pousser la couverture au-delà de la surface
Les plans générés partent d'une spécification ou d'une passe de découverte et couvrent les catégories fonctionnelle, schéma, autorisation, gestion des erreurs et limites : les cas négatifs existent donc par défaut, au lieu de dépendre de quelqu'un qui y penserait en fin de sprint.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La même configuration est disponible dans le tableau de bord TestSprite si vous préférez ne rien installer en local. Le reste de la surface du CLI se trouve dans le dépôt du CLI.
Choisir les endpoints qui reçoivent le niveau quatre
Les assertions de relation sont les plus précieuses et les plus coûteuses : elles n'ont pas leur place partout. Le filtre qui fonctionne consiste à se demander ce que coûterait une réponse erronée.
Tout ce qui déplace de l'argent, modifie des permissions ou sert de base à une décision prise par quelqu'un d'autre passe au niveau quatre. Une commande qui existe sans être rattachée à un client, une attribution de droits qui n'a réussi que d'un côté, un rapport cohérent avec lui-même mais en désaccord avec les enregistrements sous-jacents. Ce sont les défaillances coûteuses et silencieuses.
Les endpoints de reporting en lecture seule, les health checks et tout ce dont un humain examine immédiatement la sortie n'en ont pas besoin. C'est ce choix délibéré qui garde la suite assez rapide pour que les équipes la lancent.
Exécutez-la à chaque modification
Deux voies, et le choix porte en réalité sur qui possède le pipeline. Connecter la GitHub App depuis le tableau de bord ne demande aucune modification de votre dépôt, car elle réagit au déploiement que votre build émet déjà. Ajouter une étape GitHub Actions place la vérification dans le dépôt, où elle est relue comme le reste du build.
Comment TestSprite vous fait dépasser le niveau deux
Les plans générés incluent les cas négatifs par défaut, dans les catégories fonctionnelle, schéma, autorisation, gestion des erreurs et limites, précisément là où la plupart des suites écrites à la main s'essoufflent. Vous les affinez en langage courant, et c'est par cet affinage que votre connaissance du produit entre dans la suite.
Les niveaux valeur et relation sont ceux qui méritent votre attention, et ce sont aussi ceux qui exigent quelqu'un qui connaît le produit. Auto-Authentication maintient les sessions actives pendant toute l'exécution, Dynamic Variables fait circuler les valeurs d'un appel à l'autre, Dependency Chains déduit l'ordre d'exécution de ce que chaque cas requiert et produit, et Auto-Cleanup supprime exactement ce que l'exécution a créé, de sorte que votre temps passe sur la définition de ce qui est correct plutôt que sur l'infrastructure.
Vous obtenez une suite qui pose des assertions sur les corps de réponse et sur les relations entre appels, exécutée à chaque modification, plutôt qu'un pipeline vert qui prouve que le service est en ligne.
Les assertions sur le code de statut sont-elles inutiles ?
Non, elles sont simplement le minimum. Gardez-les et ajoutez au moins une assertion de niveau valeur sur chaque endpoint qui compte.
Comment décider de ce qui est correct ?
Demandez-vous ce que le produit promet, pas ce que le code fait. Si personne ne sait répondre pour un endpoint donné, cette ambiguïté mérite elle-même d'être mise au jour.
Faut-il appliquer les quatre niveaux à chaque endpoint ?
Non. Réservez les niveaux trois et quatre aux endpoints où une valeur erronée a des conséquences. Les endpoints de reporting et les health checks n'en ont pas besoin.
Et les assertions générées ?
Utiles pour les niveaux un et deux, qui sont mécaniques. Les niveaux trois et quatre gagnent à être relus, car c'est là qu'entre la connaissance du produit.
Combien de cas négatifs par endpoint ?
Un ou deux cas qui comptent valent mieux que dix qui énumèrent toutes les entrées invalides possibles. Choisissez les rejets qu'un vrai client déclencherait.
Le statut et la forme sont le minimum, pas le travail.
Les tests fonctionnels d'API comportent quatre niveaux d'assertion, et la plupart des suites s'arrêtent au deuxième. C'est avec les assertions de valeur et de relation que les défauts sont détectés, et le cas négatif est celui que l'on néglige.