Robot Framework adopte une approche différente des outils « code-first ». Au lieu d'écrire des tests sous forme de code de programme, vous les écrivez comme des tableaux de mots-clés lisibles par l'homme. Un test se lit presque comme une liste de contrôle, ce qui signifie que les analystes QA et les ingénieurs peuvent rédiger et réviser la même suite. Pour les tests d'API, la RequestsLibrary transforme les appels HTTP en ces mêmes mots-clés lisibles.
Ce guide montre comment automatiser les tests d'API avec Robot Framework de bout en bout. Vous installerez le framework et les bibliothèques dont il a besoin, écrirez votre premier test basé sur des mots-clés, gérerez les sessions à travers les requêtes, ferez des assertions sur les codes de statut et les corps JSON, et construirez des mots-clés réutilisables pour que la suite soit évolutive. Chaque exemple utilise la syntaxe de tableau de mots-clés réellement employée par Robot Framework.
Qu'est-ce que Robot Framework et pourquoi est-il adapté aux tests d'API ?
Robot Framework est un framework d'automatisation générique open-source pour l'automatisation des tests et l'automatisation robotisée des processus. Sa caractéristique principale est la syntaxe axée sur les mots-clés : les tests sont écrits dans de simples tableaux, et les comportements complexes sont construits à partir de bibliothèques de mots-clés implémentées en Python ou Java.
Pour les tests d'API, cela présente deux avantages réels. Premièrement, les tests sont lisibles par des personnes qui ne codent pas, de sorte qu'un testeur ou un chef de produit peut suivre ce qu'une suite vérifie. Deuxièmement, le framework est extensible : la RequestsLibrary enveloppe la bibliothèque Python requests et expose les opérations HTTP sous forme de mots-clés, tandis que d'autres bibliothèques couvrent JSON, les bases de données, et bien plus encore. Si la structure axée sur les mots-clés est nouvelle pour vous, notre guide plus large sur les frameworks de tests d'automatisation explique sa place parmi les autres types de frameworks.
Installation de Robot Framework et de ses bibliothèques
Robot Framework et ses bibliothèques s'installent via pip. Travaillez dans un environnement virtuel pour garder le projet propre :
python -m venv .venv
source .venv/bin/activate
pip install robotframework
pip install robotframework-requests
pip install robotframework-jsonlibrary
Les trois packages couvrent la plupart des besoins en tests d'API :
robotframeworkest le moteur principal et l'exécuteur de tests.robotframework-requests(la RequestsLibrary) envoie des requêtes HTTP sous forme de mots-clés.robotframework-jsonlibraryextrait et vérifie les valeurs à l'intérieur des réponses JSON.
Confirmez l'installation avec robot --version. Le guide de l'utilisateur officiel de Robot Framework est la référence pour les questions de syntaxe à mesure que votre suite se développe.
Un détail déroute les nouveaux venus : Robot Framework est sensible aux espaces. Les mots-clés et leurs arguments sont séparés par au moins deux espaces, pas un seul. Un espace unique est traité comme faisant partie du même jeton. La plupart des éditeurs dotés d'un plugin Robot Framework gèrent cela pour vous, mais si un test ne parvient pas à être analysé, les arguments mal espacés sont la première chose à vérifier.
Écrire votre premier test d'API
Les fichiers de test de Robot Framework utilisent l'extension .robot et sont divisés en sections marquées par *** Settings ***, *** Variables *** et *** Test Cases ***. Voici un fichier complet qui vérifie un endpoint d'utilisateurs :
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Test Cases ***
Get User Returns 200
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
Status Should Be 200 ${response}
Get User Returns Expected Email
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
${body}= Set Variable ${response.json()}
Should Be Equal As Integers ${body}[id] 42
Should Be Equal ${body}[status] active
La section *** Settings *** importe les bibliothèques. Create Session ouvre une session HTTP nommée. GET On Session envoie la requête et renvoie un objet de réponse. Status Should Be et Should Be Equal sont des mots-clés d'assertion. Exécutez la suite avec robot tests.robot, et Robot Framework génère automatiquement un rapport HTML et un journal.
Travailler avec des sessions
Create Session fait plus que stocker une URL de base. La session contient les en-têtes par défaut, l'authentification et les cookies, de sorte que chaque requête effectuée sur celle-ci hérite de cet état. C'est important pour toute API qui nécessite une connexion, car vous vous authentifiez une fois et réutilisez la session.
*** Test Cases ***
Create Order With Authenticated Session
Create Session api ${BASE_URL}
${login}= POST On Session api /auth/login
... json={"email": "qa@example.com", "password": "test-pass"}
${token}= Set Variable ${login.json()}[token]
${headers}= Create Dictionary Authorization=Bearer ${token}
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
... headers=${headers}
Status Should Be 201 ${order}
La syntaxe ... permet de continuer un appel de mot-clé sur la ligne suivante, ce qui rend les requêtes longues lisibles. Create Dictionary construit la carte des en-têtes. Comme la session persiste, vous pouvez effectuer plusieurs requêtes de suivi sans la recréer. Les mots-clés de la RequestsLibrary pour les sessions sont documentés dans la référence RequestsLibrary.
Assertions sur les corps de réponse
Vérifier le code de statut est la première étape. Pour vérifier le corps, analysez le JSON et faites des assertions sur ses champs. Les mots-clés intégrés de Robot Framework couvrent l'égalité et la contenance, et la JSONLibrary ajoute l'extraction basée sur le chemin :
*** Settings ***
Library RequestsLibrary
Library JSONLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Test Cases ***
Order Response Has Correct Shape
Create Session api ${BASE_URL}
${response}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
Status Should Be 201 ${response}
${body}= Set Variable ${response.json()}
Dictionary Should Contain Key ${body} total
Should Be Equal As Integers ${body}[quantity] 2
${status}= Get Value From Json ${body} $.status
Should Be Equal ${status}[0] pending
Dictionary Should Contain Key confirme l'existence d'un champ. Should Be Equal As Integers compare les valeurs numériques sans surprises de non-concordance de type. Get Value From Json utilise une expression JSONPath pour atteindre les données imbriquées. Pour un ensemble plus large de vérifications à effectuer sur une réponse API, notre guide sur les assertions d'API est un bon complément.
Création de mots-clés réutilisables
Répéter Create Session et le flux de connexion dans chaque test est l'équivalent du copier-coller dans une approche axée sur les mots-clés. Robot Framework vous permet de définir vos propres mots-clés dans une section *** Keywords ***, de sorte que les étapes courantes deviennent de simples lignes lisibles :
*** Keywords ***
Authenticate And Open Session
Create Session api ${BASE_URL}
${login}= POST On Session api /auth/login
... json={"email": "qa@example.com", "password": "test-pass"}
${token}= Set Variable ${login.json()}[token]
Set Suite Variable ${AUTH_HEADERS} Bearer ${token}
*** Test Cases ***
Create Order
Authenticate And Open Session
${headers}= Create Dictionary Authorization=${AUTH_HEADERS}
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2} headers=${headers}
Status Should Be 201 ${order}
Les mots-clés personnalisés sont la manière dont une suite Robot Framework reste maintenable. Lorsque le point d'accès de connexion change, vous modifiez un seul mot-clé au lieu de chaque test. Pour les suites plus grandes, déplacez les mots-clés partagés dans un fichier de ressources et importez-le, la même discipline modulaire décrite dans notre guide sur l'écriture de scripts de test automatisés.
Un fichier de ressources est un fichier .robot sans cas de test, seulement des sections *** Keywords *** et *** Variables ***. Vous l'importez depuis un fichier de test avec Resource common.robot dans les paramètres. Cela permet de regrouper le flux de connexion, l'URL de base et d'autres éléments partagés. À mesure que le projet grandit, une architecture typique comprend un fichier de ressources par zone d'API, plus un fichier de niveau supérieur pour la configuration globale. Cette séparation des cas de test de la logique de support est au cœur de la structure axée sur les mots-clés, et notre guide plus large sur les frameworks de tests d'automatisation explique pourquoi cette approche est évolutive.
Exécuter Robot Framework en CI
Robot Framework s'exécute sans interface graphique (headless) et renvoie un code de sortie non nul en cas d'échec, ce qui est exactement ce dont une pipeline a besoin pour faire échouer une compilation. L'exécuteur écrit également output.xml, log.html et report.html après chaque exécution, de sorte que les artefacts de CI sont disponibles sans configuration supplémentaire.
Quelques drapeaux (options) rendent les exécutions CI plus propres. Utilisez --outputdir pour envoyer les rapports vers un dossier connu, --include et --exclude avec des tags pour exécuter des sous-ensembles, et des fichiers de variables ou --variable pour injecter des valeurs spécifiques à l'environnement comme les URL de base et les informations d'identification sans modifier les fichiers de test :
robot --outputdir results --variable BASE_URL:https://staging.example.com/v1 tests/
Balisez vos tests avec [Tags] afin de pouvoir exécuter un ensemble de tests rapides (smoke tests) à chaque commit et la suite complète chaque nuit. L'intégration de cela dans GitHub Actions ou toute autre pipeline suit le même modèle que notre tutoriel sur les tests API en CI/CD : installer les dépendances, exécuter la commande, publier les artefacts de rapport.
Quand une plateforme API dédiée est plus utile
Robot Framework est un excellent choix lorsque vous souhaitez des tests lisibles et axés sur les mots-clés que des équipes aux compétences variées peuvent partager. Il est moins pratique lorsque vous avez également besoin de conception d'API, de simulation (mocking) et de débogage au même endroit, ou lorsque vous souhaitez une validation de schéma par rapport à une spécification OpenAPI sans l'assembler à partir de bibliothèques.
Apidog répond directement à ces besoins. Il offre un constructeur de tests visuel, une validation automatique de schéma OpenAPI, des exécutions basées sur les données depuis CSV et JSON, la gestion des environnements et des rapports HTML, avec un exécuteur CLI pour la CI. Les équipes utilisent souvent les deux : Robot Framework là où la lisibilité axée sur les mots-clés est la plus importante, et Apidog pour la conception, la simulation et les tests approfondis des API sous test. Vous pouvez télécharger Apidog et mettre en place une suite de tests d'API fonctionnelle sans écrire aucune bibliothèque de mots-clés.
Questions fréquemment posées
Robot Framework est-il uniquement destiné aux tests d'interface utilisateur ?
Non. Robot Framework est un framework d'automatisation générique. Avec la RequestsLibrary, il gère bien les tests d'API, et d'autres bibliothèques couvrent les bases de données, SSH, et plus encore. Sa conception axée sur les mots-clés est indépendante de la couche. Le framework est devenu populaire pour les tests d'interface utilisateur grâce à SeleniumLibrary, mais les tests d'API sont une utilisation tout aussi courante.
Quelle est la différence entre Create Session et une requête simple ?
Create Session ouvre une session HTTP nommée et persistante qui stocke une URL de base, des en-têtes, des cookies et l'authentification. Les mots-clés subséquents comme GET On Session réutilisent cet état, ce qui est essentiel pour les API qui nécessitent une connexion. Une requête sans session ne transporterait pas les cookies ou l'authentification entre les appels, vous obligeant à tout renvoyer à chaque fois.
Ai-je besoin de connaître Python pour utiliser Robot Framework ?
Pas pour écrire des tests. La syntaxe des tableaux de mots-clés est conçue pour les non-programmeurs, et la RequestsLibrary expose déjà les opérations HTTP sous forme de mots-clés. La connaissance de Python devient utile uniquement lorsque vous souhaitez écrire des bibliothèques de mots-clés entièrement nouvelles. La plupart des besoins en tests d'API sont couverts par les bibliothèques existantes, de sorte que de nombreuses équipes n'écrivent jamais de Python.
Comment Robot Framework se compare-t-il à Pytest pour les tests d'API ?
Pytest est « code-first » et convient aux équipes Python qui souhaitent des tests à côté du code de l'application. Robot Framework est axé sur les mots-clés et convient aux équipes aux compétences variées qui apprécient les tests lisibles sous forme de tableaux. Les deux s'exécutent en CI et produisent des rapports. Le choix dépend de qui écrit et maintient la suite plutôt que de la capacité brute.
Robot Framework peut-il valider les réponses par rapport à un schéma OpenAPI ?
Pas directement (out of the box). Vous pouvez faire des assertions sur des champs individuels avec les mots-clés intégrés et la JSONLibrary, et des bibliothèques communautaires ajoutent la vérification de schéma. Si la validation automatique par rapport à un document OpenAPI est essentielle à votre flux de travail, une plateforme comme Apidog qui le fait nativement vous évitera l'assemblage et la maintenance de bibliothèques.