Tests d'API : par quoi commencer, quoi faire ensuite, et quoi reporter

Les cinq activités que recouvrent les tests d'API

• Fonctionnel. Est-ce qu'un endpoint fait ce qu'il doit faire, y compris avec des entrées invalides ? Commencez par là. Tout le reste en dépend.

• Intégration. Est-ce que les séquences produisent le bon résultat ? C'est là que se trouvent la plupart des bugs visibles par l'utilisateur.

• Contrat. Est-ce que deux services s'accordent sur le format ? Utile quand les déploiements sont indépendants, aveugle à l'exactitude.

Les deux autres sont la charge, qui répond à la question de la capacité et exige un générateur dédié, et le comportement de sécurité, qui consiste surtout en contrôles d'autorisation et qui a sa place aux côtés de la couverture fonctionnelle plutôt que dans un exercice trimestriel.

L'ordre dans lequel les mener

1. Les tests fonctionnels, sur les endpoints qui comptent. Y compris les cas négatifs. Tout le reste se construit dessus.

2. L'intégration, sur vos vrais parcours utilisateur. Trois à cinq étapes chacun, pas douze.

3. Des contrôles d'autorisation partout. Peu coûteux, et l'autorisation au niveau des objets est la faille d'API la plus exploitée.

4. Les tests de contrat, si les services se déploient indépendamment. Inutile si vous déployez tout en même temps.

5. La charge, avant les mises en production. En dernier, parce que tester la charge d'un endpoint incorrect revient à mesurer à quelle vitesse vous pouvez vous tromper.

Les quatre problèmes, quel que soit l'outil choisi

Quatre choses 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.

Toutes les équipes les rencontrent dans le même ordre, et la plupart les découvrent par surprise. Les anticiper dès la conception fait la différence entre une suite qui dure et une suite qu'on finit par mettre en quarantaine.

L'assertion qui compte le plus

Faites vos assertions sur le corps de la réponse, pas seulement sur le statut. Un 200 qui transporte une liste vide là où un enregistrement devrait se trouver est un bug qu'une vérification du statut considère comme un succès. Cette seule habitude détecte plus de défauts réels que n'importe quel autre changement pris isolément.

Les dix premiers cas, concrètement

Quand la suite est vide, le plus dur est de décider par où commencer, et une réponse générique vous fait perdre une semaine. Voici une liste qui fonctionne pour la plupart des produits.

Trois cas pour l'objet principal de votre produit : le créer, le relire et faire des assertions sur ses champs, le supprimer et confirmer qu'il a bien disparu. Deux pour l'autorisation : la même lecture sans identifiants, puis avec les identifiants d'un second utilisateur. Deux pour les entrées : un champ obligatoire manquant et une valeur hors limites. Deux pour la séquence qui vous rend nerveux avant une mise en production, quelle qu'elle soit chez vous. Un pour l'endpoint qui a cassé la dernière fois.

Dix cas, le travail d'une matinée, et ils couvrent les schémas à l'origine de la plupart des incidents. Ensuite, l'extension doit être guidée par ce qui casse réellement plutôt que par un objectif de couverture, car la seconde approche produit des suites volumineuses et hors sujet.

Par où commencer aujourd'hui

Faites pointer un projet vers votre service, laissez la découverte recenser ce qui existe, et lisez le plan généré avant de lancer quoi que ce soit. Le plan vous en apprend plus sur votre API que ne le feront les premiers résultats, et c'est là que votre connaissance du produit vient s'ajouter.

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 CLI.

• La GitHub App est un webhook que vous configurez dans le tableau de bord TestSprite. Elle é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 place l'étape à l'intérieur de votre propre workflow, configurée depuis le terminal.

La place de TestSprite parmi ces cinq activités

Le fonctionnel, l'intégration et la moitié comportementale de la sécurité. TestSprite sollicite le service en cours d'exécution, génère des plans à partir d'une passe de découverte et de votre spécification, et couvre les cas négatifs que les suites écrites à la main laissent de côté.

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 consomme et produit, et Auto-Cleanup supprime exactement ce que l'exécution a créé. Ce sont ces quatre éléments qui décident si une suite survit à sa première année, quel que soit l'outil, et les avoir fournis par le produit fait la différence entre étendre la suite et l'entretenir.

Les tests de contrat et la charge restent des instruments à part, et tout cela fonctionne en parallèle des deux. Ce que vous obtenez, c'est la couche où vivent la plupart des défauts visibles par l'utilisateur, couverte sans framework maison et exécutée à chaque pull request.