Le rôle du testeur d'API évolue, il ne disparaît pas

Les deux moitiés du métier de testeur d'API

La génération traite bien la première colonne et ne peut rien pour la seconde, parce que celle-ci porte sur le produit et non sur le protocole.

Ce qui prend de la valeur

• Définir ce qui est correct dans les cas ambigus. Ce qui doit se passer quand une remise et une promotion s'appliquent toutes les deux. Aucune spécification ne le dit, et aucun générateur ne peut le deviner.

• Penser comme un attaquant. Puis-je commander une quantité négative, rejouer cette requête, accéder à un autre compte en changeant un identifiant ? La couverture générée inclut des contrôles d'autorisation ; elle n'invente pas l'abus auquel vous n'avez pas pensé.

• Relire la couverture générée. Un plan qui couvre une centaine d'endpoints a besoin de quelqu'un pour élaguer le bruit et ajouter les règles du produit. C'est un travail rapide et à fort effet de levier, qui mobilise exactement les connaissances d'un testeur d'API.

Ce qu'il faut cesser de faire à la main

Écrire le deux centième test CRUD. Maintenir le rafraîchissement des jetons. Câbler les fixtures pour le graphe de dépendances. Relancer et trier la même suite instable. Rien de tout cela ne mobilise les connaissances qui font la valeur d'un testeur d'API, et c'est pourtant là que passent les heures.

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 Auto-Authentication, Dynamic Variables, Dependency Chains et Auto-Cleanup, décrits dans la documentation sur les tests d'API.

La compétence la plus difficile à remplacer

Si vous vous demandez dans quoi devenir excellent, la réponse n'est pas un outil. C'est la capacité à regarder une exigence ambiguë et à nommer les trois façons dont elle peut être interprétée.

Prenez une règle du type « un utilisateur ne peut voir que ses propres commandes ». Un testeur qui exerce depuis un certain temps demande aussitôt : et un administrateur ? et une commande passée pour le compte de quelqu'un d'autre ? et une commande transférée ? que se passe-t-il après la désactivation d'un compte ? et une commande supprimée est-elle invisible ou réellement effacée ? Rien de tout cela ne figure dans l'exigence. Tout cela arrivera en production.

Aucun générateur ne produit cette liste, parce qu'elle ne découle pas de la spécification mais du fait d'avoir déjà vu des produits casser. C'est la partie du métier qui prend de la valeur à mesure que la moitié mécanique devient bon marché.

Une démarche concrète

Pointez la génération vers votre service, puis consacrez votre temps au plan plutôt qu'au code. Supprimez les routes administratives, ajoutez les règles du produit que personne n'a écrites, et ajoutez les cas négatifs qui vous viennent parce que vous connaissez le domaine. Vous couvrirez plus en une journée qu'en une semaine d'écriture à la main, et la couverture contiendra vos connaissances plutôt que celles d'une spécification.

La même configuration est disponible dans le tableau de bord TestSprite si vous préférez ne rien installer en local. Le reste des commandes du CLI se trouve dans le dépôt du CLI.

Le déclencheur compte plus que le mécanisme. Le brancher sur votre événement de déploiement signifie que chaque changement est vérifié sans que personne ait à le décider ; la GitHub App le fait depuis le tableau de bord, et une étape GitHub Actions le fait depuis l'intérieur de votre workflow.

Là où TestSprite vous laisse le jugement

Il prend en charge la colonne mécanique. API Discovery recense ce que le service expose, les plans sont générés sur les catégories fonctionnelle, schéma, autorisation, gestion des erreurs et valeurs limites, 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éé.

Ce qu'il ne fait délibérément pas, c'est décider de ce qui est correct. Le plan généré est un point de départ que vous élaguez, corrigez et étendez, et c'est par ce travail d'édition que votre connaissance du produit entre dans la suite. Une heure passée sur un plan couvre plus qu'une semaine d'écriture à la main, et la couverture contient votre jugement plutôt que celui d'une spécification.

Le résultat concret pour le métier : vous cessez d'écrire le deux centième test CRUD et consacrez ce temps aux règles ambiguës et aux cas d'abus, c'est-à-dire au travail qui a toujours justifié votre présence.