Écrire un script de test automatisé est facile. Écrire un script qui conserve son utilité six mois plus tard est la partie difficile. De nombreux scripts de test sont écrits, passent au vert une fois, puis pourrissent tranquillement, se cassant sur des changements non liés, n'affirmant rien de significatif et habituant l'équipe à ignorer les builds rouges. Un bon script de test est précis, isolé et durable.
Ce guide couvre ce qu'est un script de test automatisé, la structure qui le rend fiable, deux façons d'écrire des scripts de test API, et une construction étape par étape dans Apidog.
Qu'est-ce qu'un script de test automatisé
Un script de test automatisé est un ensemble d'instructions défini et reproductible qui exerce une partie de votre logiciel et vérifie le résultat, sans qu'un humain n'exécute les étapes. Le script envoie une entrée, effectue une action et compare le résultat à une attente. S'ils correspondent, il passe. Sinon, il échoue et indique pourquoi.
Un script de test est la forme exécutable d'un cas de test. Le cas de test décrit l'intention, l'entrée, l'action et le résultat attendu, en termes humains. Le script transforme cette intention en quelque chose qu'une machine exécute à chaque commit. Un cas de test peut devenir un script ; un scénario de test se compose généralement de plusieurs scripts enchaînés.
La valeur intrinsèque d'un script de test automatisé est qu'il s'exécute de la même manière à chaque fois. Cela n'est vrai que si le script est écrit pour être déterministe. Un script qui dépend de l'ordre d'exécution d'autres scripts, ou de données laissées par une exécution précédente, n'est pas une automatisation fiable ; c'est une source d'instabilité.
La structure d'un script de test fiable
Presque tous les scripts de test bien écrits, quel que soit le langage ou l'outil, suivent la même structure en quatre parties. On l'appelle souvent Arrange-Act-Assert, avec le nettoyage en plus.
Arranger (Arrange). Mettre en place tout ce dont le test a besoin : les données d'entrée, l'authentification, les préconditions. Le script doit créer son propre état plutôt que de supposer qu'il existe. Si le test a besoin d'un utilisateur, il en crée un, ou utilise un composant connu, et non ce qui se trouve dans la base de données.
Agir (Act). Effectuer l'unique action testée. Un bon script teste un seul comportement. Envoyer une requête, appeler une fonction, déclencher un événement, c'est l'acte, et il ne devrait y en avoir qu'un par script.
Affirmer (Assert). Vérifier le résultat par rapport aux attentes. C'est la partie dans laquelle les équipes sous-investissent. Un script qui ne fait qu'affirmer "aucune erreur n'a été levée" ou "le statut était 200" ne teste presque rien. Des assertions solides vérifient les valeurs réelles : le corps de la réponse, le schéma, les effets secondaires, le timing.
Nettoyer (Cleanup). Annuler ce que le script a créé afin qu'il puisse s'exécuter à nouveau à partir d'une page blanche. Un script qui laisse des données de test derrière lui finira par entrer en collision avec lui-même ou avec un autre script.
Trois habitudes distinguent les scripts durables des scripts fragiles. Tester une seule chose par script, afin qu'un échec ait une cause évidente. Garder les scripts indépendants, afin qu'ils s'exécutent dans n'importe quel ordre. Et affirmer sur des valeurs stables, jamais sur des données volatiles comme les ID générés ou les horodatages, qui font échouer un script sans réelle raison.
Deux façons d'écrire des scripts de test API
Pour les tests d'API spécifiquement, il existe deux approches courantes, et elles conviennent à différentes équipes.
L'approche "code-first" écrit des scripts de test dans un langage de programmation généraliste. En Python, cela signifie un framework comme pytest plus une bibliothèque HTTP ; en JavaScript, un exécuteur de tests plus fetch. Vous écrivez la requête, les assertions et la configuration sous forme de code réel, et les scripts résident dans votre dépôt aux côtés de l'application.
Cette approche offre un contrôle programmatique complet. La logique complexe, les composants personnalisés et les assertions inhabituelles ne sont que du code. Le coût est que chaque script est du code que vous écrivez et maintenez, que l'équipe a besoin des compétences linguistiques, et que beaucoup de code passe-partout, de gestion d'authentification, de construction de requêtes, d'analyse de réponses, est réécrit d'un script à l'autre. Elle convient aux équipes d'ingénieurs qui souhaitent que les tests soient versionnés avec le code et qui sont à l'aise avec cette maintenance.
L'approche visuelle construit le script de test dans un outil de test API dédié. Vous définissez la requête, ajoutez des assertions en cliquant et enchaînez les requêtes dans des scénarios, sans écrire ni maintenir de code de script pour les cas courants. Des outils comme Apidog adoptent cette voie.
Cette approche supprime le code passe-partout et rend les scripts lisibles par tous les membres de l'équipe, pas seulement ceux qui connaissent le langage. Vous devez toujours recourir à du code personnalisé pour la logique rare que le constructeur visuel ne peut pas exprimer. Elle convient aux équipes mixtes, aux tests pilotés par l'assurance qualité et à tous ceux qui veulent une suite de tests fonctionnant rapidement sans projet de script annexe.
Aucune n'est mauvaise. La question décisive est de savoir qui maintient les scripts et s'ils doivent résider dans le dépôt de l'application. Pour la plupart des tests d'API, l'approche visuelle permet d'obtenir une suite fiable plus rapidement et avec moins de maintenance.
Écrire un script de test API automatisé dans Apidog
Voici le déroulement complet pour construire visuellement un script de test API durable.
Étape 1 : Définir la requête. Importez le point d'accès dans Apidog à partir d'un fichier OpenAPI ou définissez-le directement. C'est l'étape d'arrangement ; la requête contient sa méthode, son chemin, ses en-têtes et son corps.
Étape 2 : Ajouter les données de test. Définissez la charge utile d'entrée pour le cas que vous testez. Pour couvrir de nombreuses entrées avec un seul script, joignez un fichier CSV ou JSON afin que le script s'exécute une fois par ligne ; le test basé sur les données remplace une douzaine de scripts quasi identiques par un seul.
Étape 3 : Écrire les assertions. C'est le cœur. Ajoutez des vérifications visuelles : le statut est égal au code attendu, les champs clés du corps existent et ont les bonnes valeurs, la réponse est conforme au schéma, le temps de réponse est dans le budget. Pour les cas négatifs, affirmez la forme de l'erreur, pas seulement le code d'échec. Résistez à l'envie d'affirmer des données volatiles.
Étape 4 : Enchaîner les requêtes dans un scénario. Les flux de travail réels s'étendent sur plusieurs appels. Construisez un scénario qui se connecte, crée une ressource, la relit et la supprime, en passant les valeurs d'une étape à la suivante. Chaque étape est un script ; ensemble, elles testent un flux complet.
Étape 5 : Ajouter une logique de script personnalisée uniquement si nécessaire. Pour les vérifications que les assertions visuelles ne peuvent pas exprimer, la logique conditionnelle, les valeurs calculées, les comparaisons inter-requêtes, ajoutez un pré- ou post-processeur JavaScript. Gardez cela minimal ; la plupart des scripts n'en ont jamais besoin.
Étape 6 : L'exécuter et lire le rapport. Exécutez le scénario. Apidog exécute chaque script, évalue chaque assertion et signale la vérification exacte qui a échoué avec les valeurs attendues et réelles côte à côte.
Étape 7 : Automatiser l'exécution. Intégrez le scénario dans la CI/CD afin qu'il s'exécute à chaque commit. Un script de test qui ne s'exécute que lorsque quelqu'un s'en souvient n'est pas réellement automatisé. Téléchargez Apidog pour construire votre premier scénario.
Maintenir les scripts de test en bonne santé
Une suite de tests est une chose vivante. Les scripts qui étaient parfaits lors de la publication deviennent obsolètes à mesure que l'API évolue. Trois pratiques permettent de maintenir la fiabilité d'une suite.
Mettez à jour les scripts avec l'API, pas après. Lorsqu'un contrat de point d'accès change, le script change dans le même commit. Un script qui affirme un ancien schéma échoue pour la mauvaise raison et érode la confiance dans tous les autres scripts.
Traitez les scripts instables comme de véritables bugs. Un script qui passe la plupart du temps est pire qu'aucun script, car il enseigne à l'équipe que le rouge ne signifie pas "cassé". Trouvez la cause, généralement un état partagé ou une hypothèse de timing, et corrigez-la.
Revoyez les scripts comme du code de production. Un script avec des assertions faibles, une vérification "200 seulement", semble vert et sûr tout en ne testant presque rien. Un deuxième lecteur le remarquera.
Questions fréquemment posées
Quelle est la différence entre un cas de test et un script de test ? Un cas de test décrit l'intention en termes humains : entrée, action, résultat attendu. Un script de test est la version exécutable qu'une machine exécute. Le cas est le plan ; le script est l'implémentation.
Ai-je besoin de savoir coder pour écrire des scripts de test automatisés ? Pas pour les tests d'API avec un outil visuel. Dans Apidog, vous construisez des requêtes, des assertions et des scénarios en cliquant, et n'écrivez du code que pour une logique inhabituelle. Les frameworks "code-first" nécessitent des compétences en langage.
Pourquoi mes scripts de test continuent-ils de casser ? Les causes habituelles sont les assertions sur des données volatiles, les scripts qui dépendent de l'état des autres, et l'absence de mise à jour des scripts lorsque l'API change. Isolez les données de test, gardez les scripts indépendants et mettez-les à jour avec le contrat.
Combien d'assertions un script de test doit-il contenir ? Suffisamment pour vérifier véritablement le résultat, généralement le statut, les champs clés du corps, le schéma et le timing. Une seule assertion de code de statut est trop peu ; elle passe alors que la réponse est erronée.
Les scripts de test doivent-ils résider dans le dépôt de l'application ? Avec une approche "code-first", généralement oui, afin que les tests soient versionnés avec le code. Avec un outil visuel, les scripts résident dans la plateforme de test et se synchronisent avec la définition de l'API. Les deux fonctionnent ; la cohérence est plus importante que le choix.
Comment écrire des scripts de test avant que l'API ne soit construite ? Écrivez-les en fonction de la conception de l'API. Si vous avez une spécification OpenAPI, vous pouvez y définir des requêtes et des assertions, puis les exécuter contre un serveur simulé jusqu'à ce que le point d'accès réel existe. Les scripts sont prêts dès que l'implémentation est en place.
Quelle est la différence entre un script de test et une suite de tests ? Un script de test exécute une vérification. Une suite de tests est une collection de scripts regroupés pour s'exécuter ensemble, couvrant souvent une API ou une fonctionnalité entière. Les suites permettent d'organiser un ensemble croissant de scripts et de lancer une large couverture en une seule commande.
Quelle doit être la longueur d'un script de test automatisé ? Aussi court que possible tout en effectuant les quatre parties : arranger, agir, affirmer, nettoyer. Si un script est long, il teste généralement plus d'une chose et devrait être divisé. Un comportement par script facilite le diagnostic des échecs.