Automatisation des tests d'API qui résiste à un vrai backend

Pourquoi l'automatisation des tests d'API cale toujours sur les quatre mêmes points

Toutes les équipes commencent de la même manière. Quelqu'un écrit une requête vers un seul endpoint, vérifie un code de statut et l'intègre à la CI. Ça marche. Puis la suite grandit, et quatre problèmes arrivent, à peu près dans le même ordre pour tout le monde.

Les tokens expirent : la suite passe le matin et échoue à midi. Les réponses contiennent des valeurs dont la requête suivante a besoin : soit les tests les codent en dur, soit ils cassent. Certains endpoints ne peuvent pas être appelés tant que quelque chose d'autre n'a pas été créé : l'ordre se met à compter, et personne ne l'a écrit nulle part. Et chaque exécution laisse des lignes derrière elle : la dixième exécution ne se comporte plus comme la première.

Rien d'exotique là-dedans. C'est la forme ordinaire d'un vrai backend. Ce qui sépare une suite qui dure d'une suite supprimée au bout d'un trimestre, c'est de savoir si ces quatre points ont été anticipés dès la conception ou découverts en chemin.

Partez de ce que le service expose réellement

Avant tout cela, il vous faut un inventaire. Écrire des tests de mémoire produit une suite qui couvre les endpoints auxquels vous avez pensé, c'est-à-dire en général ceux qui fonctionnaient déjà.

Deux sources vous donnent une image fidèle. Un document de spécification, comme un fichier OpenAPI ou un document d'exigences produit, vous dit ce qui est censé exister. Une passe de découverte sur le service en fonctionnement vous dit ce qui existe vraiment. L'écart entre les deux est intéressant en soi, et c'est un bien meilleur point de départ qu'une page blanche pour décider de la couverture. Dans TestSprite, cette première étape s'appelle API Discovery : elle accepte un PRD, une documentation d'API ou l'observation des appels réels.

Ensuite, vous choisissez les endpoints qui méritent d'être couverts plutôt que de tout accepter. Un plan généré qui inclut chaque route administrative et interne, c'est du bruit — et c'est par le bruit qu'une suite perd son public.

Problème un : l'authentification (Auto-Authentication)

L'approche naïve consiste à placer un token dans une variable d'environnement et à le renouveler à la main quand quelqu'un remarque des échecs. Ça tient jusqu'aux vacances de la personne qui est au courant.

Ce qu'il vous faut, c'est que les identifiants appartiennent à l'environnement plutôt qu'à un test en particulier, et que la connexion fasse partie de l'exécution. TestSprite appelle cela Auto-Authentication : vous configurez le parcours de connexion une fois, et un token frais est récupéré avant chaque exécution. Deux principes comptent plus qu'ils n'en ont l'air.

• Séparez les identifiants du test. Un test qui contient un mot de passe ne peut pas être partagé, ne peut pas être pointé vers un deuxième environnement et ne peut pas être commité. Le cas de test doit dire « en tant qu'utilisateur connecté », pas « en tant que user@example.com avec ce mot de passe ».

• Authentifiez-vous une seule fois par exécution, là où le service le permet. Tout service doté d'une limite de débit sur la connexion finira par rejeter une suite qui se connecte à chaque cas de test, et ces rejets ressemblent exactement à des bugs produit. Diagnostiquer ce type de faux échec coûte plus de temps que de concevoir la suite pour l'éviter.

Problème deux : les valeurs qui n'existent qu'à l'exécution (Dynamic Variables)

Un appel de création renvoie un identifiant. Les appels de mise à jour et de suppression en ont besoin. Si l'identifiant est collé en dur dans le test, le test n'est valable qu'une seule fois.

La solution consiste à capturer la valeur dans la réponse et à y faire référence plus tard, pour que la suite transmette les données au lieu de les supposer. En pratique, cela signifie qu'un test ne dit pas DELETE /orders/8412. Il dit de supprimer la commande créée par cette exécution, quel que soit l'identifiant obtenu.

Écrit noir sur blanc, cela paraît évident, et c'est pourtant la raison la plus fréquente pour laquelle une suite qui passait le mois dernier échoue aujourd'hui. Le mécanisme porte un nom chez TestSprite, Dynamic Variables : capturer une valeur dans une réponse et l'injecter dans la requête suivante, avec un câblage déduit automatiquement plutôt que maintenu à la main.

Problème trois : les endpoints qui dépendent les uns des autres (Dependency Chains)

Vous ne pouvez pas ajouter un article à un panier qui n'existe pas. Vous ne pouvez pas valider une commande pour un panier vide. Une vraie couverture d'API n'est pas une liste plate d'appels, c'est un graphe.

Quand ce graphe reste implicite, deux choses tournent mal. Les tests s'exécutent dans un ordre qui fonctionne par hasard sur une machine et pas sur une autre, et un seul échec en début de chaîne produit vingt échecs en aval qui ressemblent tous à des bugs distincts.

Rendre les dépendances explicites règle les deux. Chaque cas déclare ce dont il a besoin et ce qu'il produit, l'exécution en déduit un ordre sûr, et quand quelque chose échoue vous obtenez un échec et dix-neuf tests ignorés plutôt que vingt lignes rouges à éplucher. C'est toute la différence entre les Endpoint Tests, qui couvrent une route à la fois, et les Integration Tests, des chaînes en plusieurs étapes où chaque réponse alimente la suivante.

Problème quatre : les données que vous laissez derrière vous (Auto-Cleanup)

Une suite qui crée des enregistrements sans jamais les supprimer se dégrade à son propre rythme. Les listes s'allongent, les assertions sur la pagination dérivent, les contraintes d'unicité se déclenchent, et un vendredi quelqu'un finit par vider une table à la main.

Le nettoyage doit faire partie de l'exécution et être lié aux ressources créées par cette exécution précise. Nettoyer par motif, par exemple en supprimant tout ce dont le nom commence par test-, fonctionne jusqu'à ce que deux exécutions se chevauchent ou qu'une personne de l'entreprise crée un enregistrement au nom malheureux. Auto-Cleanup supprime les enregistrements créés par une exécution à la fin de celle-ci, et c'est cette version-là qui résiste à la concurrence.

À quoi ressemble, de bout en bout, une automatisation des tests d'API qui fonctionne

En réunissant les quatre, voici à quoi ressemble une configuration qui tient sur un an.

Intégrer la suite au pipeline

Une suite d'API qui s'exécute quand quelqu'un y pense est une suite qui s'exécute avant les releases et pas avant les merges, c'est-à-dire du mauvais côté. Il y a deux points d'entrée, et le choix porte sur qui doit maîtriser le déclenchement.

À savoir avant de choisir : il existe deux surfaces, et elles résolvent la question différemment. Le portail web est la voie « générer et maintenir », où la découverte, le câblage des dépendances et le nettoyage sont déduits pour vous. Le CLI est la voie « apportez votre propre code » : les tests backend y sont du Python que vous écrivez, c'est vous qui déclarez ce dont chacun a besoin et ce qu'il produit, et le teardown est un test que vous marquez comme tel. Les mêmes quatre problèmes, une répartition du travail différente. Les équipes qui veulent que la suite vive dans leur dépôt choisissent délibérément la seconde.

Deux voies, et le choix porte sur l'endroit où vous voulez que vive la configuration.

Deux voies, et le choix porte en réalité sur qui est responsable du pipeline. Connecter la GitHub App depuis le tableau de bord ne demande aucune modification de votre dépôt, puisqu'elle réagit au déploiement que votre build produit 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 commandes actuelles se trouvent dans le dépôt du CLI.

Deux limites assumées

Il s'agit de vérification fonctionnelle. Les plans générés incluent bien des cas aux limites et des cas d'autorisation : une exécution vous dira donc si une valeur hors plage est rejetée et si une requête non authentifiée est refusée. Ce n'est pas la même chose que des tests de charge ou un scan de vulnérabilités. Cela ne vous dira pas comment le service se comporte sous une concurrence soutenue, et ce n'est pas un scanner. Ce sont des instruments distincts, et prétendre le contraire vous fera perdre votre après-midi.

Cela ne sauvera pas non plus une API sans spécification ni conventions cohérentes. La découverte peut énumérer les endpoints, mais décider de ce que « correct » veut dire pour chacun reste un jugement, et quelqu'un dans votre équipe doit le porter. Le travail est moindre que d'écrire la suite à la main, mais il n'est pas nul.

Comment TestSprite traite ces quatre problèmes

Les quatre points de rupture décrits sur cette page ne sont pas accessoires aux tests d'API : ils sont donc pris en charge par le produit plutôt que laissés à votre infrastructure. Auto-Authentication reprend le parcours de connexion une fois pour toutes et récupère un token frais avant chaque exécution. Dynamic Variables transporte une valeur d'une réponse vers la requête suivante. Dependency Chains déduit un ordre d'exécution sûr à partir de ce dont chaque cas a besoin et de ce qu'il produit. Auto-Cleanup supprime exactement les enregistrements créés par une exécution, et c'est cette version-là qui résiste à l'exécution en parallèle.

La couverture vient elle aussi d'ailleurs. API Discovery énumère ce que le service en fonctionnement expose réellement, Plan Generation propose des cas dans les catégories fonctionnelle, schéma, autorisation, gestion des erreurs et valeurs limites, et vous les affinez en langage courant. Le résultat inclut les cas négatifs que personne n'écrit en fin de sprint.

Ce que cela vous laisse : une suite qui continue de fonctionner à mesure que l'API évolue, sans conftest ni répertoire utilitaire qu'une seule personne comprend. La tenue en charge et le scan de vulnérabilités restent des instruments distincts.

Chacun des quatre a sa propre page dans la documentation sur les tests d'API si vous voulez les mécanismes plutôt que le raisonnement.