Une cartographie des outils de test par apport spécifique
Unitaire
Ce qu'elle est seule à détecter : une logique fausse, en quelques millisecondes, avec une localisation précise de la défaillance.
Le retour le moins coûteux qui soit. Rien ne le remplace.
API
Ce qu'elle est seule à détecter : un comportement incorrect à la frontière du service, y compris des cas qu'aucune interface n'expose.
Plus rapide et plus précis que de piloter un navigateur.
De bout en bout
Ce qu'elle est seule à détecter : le produit assemblé qui échoue alors que chaque partie fonctionne.
La plus lente, et la seule couche qui réponde à la question de l'utilisateur.
Autour de ces couches gravitent trois spécialistes : les tests de contrat pour la dérive des formats entre services déployés indépendamment, les tests de charge pour la capacité, et l'analyse de sécurité pour les classes de vulnérabilités connues. Chacun détecte quelque chose qui échappe aux trois couches principales, et aucun ne s'y substitue.
Où se situe généralement la lacune
La plupart des équipes ont des tests unitaires et une certaine couverture de bout en bout, avec un milieu très mince. C'est l'inverse de ce qu'il faudrait, car la couche API détecte la majorité des défauts visibles par l'utilisateur pour une fraction du coût de la couche au-dessus.
La seconde lacune courante : la couverture progresse moins vite que le volume de code. Cela ne se corrige pas avec une catégorie d'outils de plus, mais avec une couverture qui ne dépend pas de la quantité de tests qu'une personne peut écrire.
La question qui vaut mieux qu'un tableau de fonctionnalités
Quelle que soit la couche pour laquelle vous cherchez un outil, demandez-vous à quoi ressemble un échec pour la personne qui devra le corriger, et si une exécution qui n'a jamais atteint ses assertions est rapportée comme un succès. Ces deux critères prédisent la valeur d'un outil mieux que tout ce qui figure sur sa page comparative.
L'outil que vous avez déjà et que vous n'utilisez pas
Avant d'ajouter quoi que ce soit, il vaut la peine de vérifier ce qui est déjà installé et inutilisé, car la plupart des organisations disposent de plus de capacités de test qu'elles n'en exploitent.
Il y a généralement un framework de tests unitaires avec une poignée de tests datant d'il y a deux ans. Il y a souvent une suite navigateur qui s'exécute chaque nuit et que personne ne lit. Il y a fréquemment un scanner qui déverse un rapport dans un canal mis en sourdine. Chacun a été acheté ou mis en place pour une raison et a cessé d'être utilisé pour une raison, et cette raison mérite d'être connue avant de dépenser à nouveau dans la même catégorie.
La réponse habituelle : des résultats sur lesquels personne n'agit finissent ignorés, ce qui relève du processus et non de l'outillage. Un nouvel outil hérite du même processus et aboutit au même point, simplement plus tard et à un coût plus élevé.
Où consacrer la prochaine heure
Le parcours que vous seriez gêné de casser, couvert de bout en bout.
L'API qui le sous-tend, couverte, cas négatifs compris.
Ce qui a cassé en dernier, transformé en contrôle permanent.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Le tableau de bord couvre le même périmètre pour qui ne souhaite pas d'installation locale, et l'intégralité des commandes se trouve dans le dépôt CLI.
La GitHub App est un webhook que vous configurez dans le tableau de bord TestSprite. Il écoute l'événement de déploiement que votre pipeline produit déjà, si bien que rien ne change dans votre dépôt.
GitHub Actions insère l'étape dans votre propre workflow, configurée depuis le terminal.
Où se situe TestSprite sur cette cartographie
Sur la couche API et la couche de bout en bout, les deux où se concentre la majorité des défauts visibles par l'utilisateur et où se trouve la lacune habituelle. TestSprite sollicite le produit en cours d'exécution plutôt qu'un mock, génère la couverture à partir de vos sources et d'une passe de découverte, et l'affine en langage naturel.
Auto-Authentication maintient les sessions actives pendant toute une exécution, Dynamic Variables transporte les valeurs d'un appel à l'autre, Dependency Chains déduit l'ordre d'exécution et Auto-Cleanup supprime exactement ce que l'exécution a créé. Les étapes navigateur expriment des intentions plutôt que des sélecteurs : une refonte ne fait donc pas passer la suite au rouge.
Les tests unitaires restent les vôtres et restent le retour le moins coûteux dont vous disposez. Les tests de contrat, les tests de charge et l'analyse de sécurité restent des instruments distincts. L'intérêt : le milieu trop mince se remplit sans ajouter une charge de rédaction qui entre en concurrence avec les livraisons.
Combien d'outils de test faut-il avoir ?
Le minimum qui couvre les couches dont vous avez besoin. Chaque outil supplémentaire est une chose de plus à configurer, à exécuter et à interpréter.
La pyramide des tests est-elle toujours valable ?
Sa forme reste un point de départ raisonnable. La version utile n'est pas un ratio : c'est de se demander ce que chaque couche est seule à détecter.
Faut-il standardiser entre les équipes ?
Pour le reporting et l'intégration à la CI, oui. Imposer un seul outil à toutes les équipes aboutit généralement à un outil qu'une équipe utilise bien et que les autres évitent.
Quelle est la lacune la plus fréquente ?
Une couche API trop mince. Les équipes passent directement de l'unitaire au bout en bout et manquent le niveau où la majorité des défauts visibles par l'utilisateur se détectent au moindre coût.
Comment savoir si un outil justifie sa place ?
Aux défauts échappés qu'il détecte, et au fait que quelqu'un lise ou non ses résultats. Un outil que personne ne lit n'est qu'un abonnement.
Cartographiez par apport spécifique, pas par catégorie.
Les outils de test méritent d'être cartographiés selon ce que chaque couche est seule à détecter. La lacune courante est une couche API trop mince, et la question qui vaut mieux que n'importe quel tableau de fonctionnalités est celle de savoir à quoi ressemble un échec pour la personne qui devra le corriger.