Les méthodes de test d'API classées par ce qu'elles seules détectent
Smoke
Détecte : le déploiement est cassé.
Coût : quelques minutes. À exécuter systématiquement. Rien d'autre ne vous l'apprend aussi vite.
Fonctionnel
Détecte : un comportement erroné sur un endpoint, y compris face à des entrées invalides.
Coût : modéré. La base que tout le reste présuppose.
Intégration
Détecte : des séquences qui échouent alors que chaque étape réussit.
Coût : plus élevé, à cause de l'état. Le meilleur rendement sur les bugs visibles par l'utilisateur.
La régression n'est pas une méthode à part, c'est une cadence : exécuter ce que vous avez déjà à chaque changement. Le test de contrat détecte les dérives de format entre des services déployés indépendamment. Le test de charge détecte les limites de capacité. Le fuzzing détecte les plantages sur des entrées malformées. Le test du comportement de sécurité détecte les erreurs d'autorisation et coûte bien moins cher que sa réputation ne le laisse croire.
Celle que tout le monde classe mal
Les tests de régression sont listés comme une méthode, puis planifiés comme une activité, généralement avant les mises en production. C'est là l'erreur. La régression, c'est ce que font vos tests existants lorsqu'ils s'exécutent, et leur valeur dépend presque entièrement de la fréquence à laquelle cela arrive. Une suite de régression exécutée une fois par mois est une suite qui trouve les problèmes avec un mois de retard.
Choisir sans tout faire
Smoke et fonctionnel sur les endpoints critiques. La couverture utile la moins chère qui existe.
L'intégration sur de vrais parcours. C'est là que vivent réellement les bugs que rencontrent vos utilisateurs.
Les vérifications d'autorisation. Peu coûteuses, et c'est la faille la plus souvent exploitée dans les API réelles.
Le contrat, uniquement si les services se déploient indépendamment.
La charge et le fuzzing, quand les enjeux le justifient. Les deux sont pertinents, et les deux sont le mauvais premier investissement.
Boîte noire contre boîte blanche
Une distinction qui compte moins qu'avant pour le travail sur les API. Tester à travers l'interface publique est le bon choix par défaut, parce que c'est ce qu'utilisent vos clients. La connaissance en boîte blanche sert à choisir quoi tester, pas à décider comment le tester.
Là où la pyramide induit en erreur pour les API
La pyramide des tests a été dessinée pour un monde fait d'unités et d'interfaces utilisateur, et l'appliquer telle quelle aux API produit une erreur courante.
La pyramide dit de garder peu de tests lents au sommet. Pour les API, la couche coûteuse n'a rien d'évident : un test d'API coûte bien moins cher qu'un test navigateur et bien plus cher qu'un test unitaire, et il détecte des choses qu'aucun des deux ne détecte. Les équipes qui placent les tests d'API au sommet étroit de la pyramide finissent par en avoir trop peu, et celles qui les rangent dans la base large se retrouvent avec une suite lente, pleine d'assertions triviales.
Un meilleur modèle mental pour les services consiste à se demander quelle couche est seulement capable de répondre à une question donnée. Savoir si un calcul est juste relève du test unitaire. Savoir si l'endpoint l'applique correctement relève du test d'API. Savoir si l'utilisateur y accède un jour relève d'un niveau supérieur aux deux. Les proportions découlent alors de votre produit, et non d'un schéma.
Ce dont toutes les méthodes ont besoin en dessous
Quatre choses déterminent si une suite d'API survit à sa première année : des sessions qui expirent, des valeurs qui n'existent qu'à l'exécution, des appels qui dépendent les uns des autres, et des enregistrements que personne ne nettoie. TestSprite les prend en charge avec Auto-Authentication, Dynamic Variables, Dependency Chains et Auto-Cleanup, décrits dans la documentation sur les tests d'API.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Le tableau de bord couvre le même terrain pour qui ne veut pas d'installation locale, et l'ensemble des commandes se trouve dans le dépôt du CLI.
Deux voies, et le choix porte en réalité sur qui possède le pipeline. Connecter la GitHub App depuis le tableau de bord n'exige aucune modification de votre dépôt, puisqu'elle réagit au déploiement que votre build émet déjà. Ajouter une étape GitHub Actions place le contrôle dans le dépôt, où il est relu comme le reste du build.
Les méthodes couvertes par TestSprite
Le fonctionnel et l'intégration, plus la partie comportementale de la sécurité, plus la régression comme cadence plutôt que comme activité. Les plans générés couvrent les catégories fonctionnelle, schéma, autorisation, gestion des erreurs et cas limites, affinés en langage courant.
Auto-Authentication maintient les sessions actives pendant toute l'exécution, Dynamic Variables transporte les valeurs d'un appel à l'autre, Dependency Chains déduit l'ordre d'exécution de ce que chaque cas exige et produit, et Auto-Cleanup supprime exactement ce que l'exécution a créé. C'est ce qui permet à la régression d'être réellement continue au lieu d'être planifiée avant les mises en production, ce qui constitue le facteur le plus déterminant du rendement de n'importe quelle méthode.
Le contrat, la charge et le fuzzing restent des instruments distincts. L'intérêt, c'est que les trois méthodes au meilleur rendement cessent de disputer du temps d'écriture au développement de fonctionnalités : la couverture existe au lieu d'être planifiée.
Quelle méthode trouve le plus de bugs ?
L'intégration, dans la plupart des produits, parce que les défaillances visibles par l'utilisateur apparaissent généralement entre les appels plutôt qu'à l'intérieur d'un seul.
Les tests smoke méritent-ils une suite séparée ?
Oui. Une vérification de deux minutes qui s'exécute à chaque déploiement n'a pas le même rôle qu'une suite de vingt minutes, et les confondre revient à n'exécuter ni l'une ni l'autre au bon moment.
Avons-nous besoin de fuzzing ?
Si des entrées malformées atteignant votre service ont de vraies conséquences, oui. Pour la plupart des API internes, cela passe après les vérifications d'autorisation et la couverture d'intégration.
Et les tests exploratoires d'API ?
Réellement utiles et non automatisables. Pratiquez-les quand une API est nouvelle ou a beaucoup changé, puis codifiez ce que vous avez trouvé.
Comment tout cela se rattache-t-il à la pyramide des tests ?
De façon lâche. La pyramide a été conçue pour l'unitaire et l'UI. Pour les API, l'axe utile est ce que chaque vérification est seule à détecter, plutôt que la couche à laquelle elle appartient.
Choisissez selon ce que chaque méthode est seule à détecter.
Les méthodes de test d'API méritent d'être classées par coût rapporté à leur apport unique plutôt que mémorisées. Smoke et fonctionnel d'abord, intégration pour les vrais bugs, vérifications d'autorisation parce qu'elles coûtent peu, et charge en dernier.