Selenium est un framework d'automatisation de navigateur. Il pilote Chrome, Firefox et d'autres navigateurs comme le ferait une personne : en cliquant sur des boutons, en remplissant des formulaires, en lisant la page rendue. C'est l'outil standard pour les tests d'interface utilisateur de bout en bout, et il excelle dans ce domaine.
Les gens se demandent toujours si Selenium peut tester les API. La réponse honnête est que vous pouvez le faire émettre des appels HTTP, mais ce n'est pas le bon outil pour ce travail. Ce guide explique exactement pourquoi, montre à quoi ressemble réellement le test d'API via Selenium, et vous oriente vers les outils conçus pour cette tâche. L'objectif est de vous éviter une configuration qui vous frustrera plus tard.
Pourquoi Selenium et les tests d'API ne correspondent pas
Un test d'API envoie une requête HTTP directement à un serveur et vérifie la réponse : code de statut, en-têtes, corps, temps de réponse. Aucune interface utilisateur n'est impliquée. Le test doit être rapide, isolé et peu coûteux à exécuter des milliers de fois.
Selenium fait l'inverse par conception. Il lance un vrai navigateur, charge des pages et attend que JavaScript se rende. Ce navigateur est l'intérêt principal lorsque vous testez une interface utilisateur, et c'est une surcharge pure lorsque vous testez une API. Une requête qu'un client dédié envoie en dizaines de millisecondes devient une affaire de plusieurs secondes une fois que vous impliquez un processus de navigateur, une session WebDriver et le rendu de la page.
Il y a aussi un décalage plus profond. L'API entière de Selenium concerne les éléments d'une page : trouver ce bouton, lire ce texte, attendre cet élément. Une réponse HTTP n'est pas une page. Elle n'a pas de DOM. Donc Selenium ne vous offre rien d'utile pour inspecter un corps JSON, faire une assertion sur un en-tête ou vérifier un code de statut. Vous finissez par contourner l'outil au lieu de l'utiliser.
Le coût n'est pas seulement la vitesse. Les tests basés sur le navigateur sont notoirement fragiles. Ils échouent parce qu'une page a mis un peu plus de temps à se rendre, parce qu'une session WebDriver a été interrompue, ou parce qu'une mise à jour du navigateur a modifié un certain timing. Un test d'API doit être déterministe : la même requête produit la même réponse, et un échec signifie que quelque chose a réellement cassé. Acheminer les vérifications d'API via Selenium importe toute cette fragilité du navigateur dans une couche qui n'a aucune raison d'être fragile. Avec le temps, une suite fragile entraîne l'équipe à ignorer les builds en rouge, ce qui va à l'encontre du but des tests. La distinction entre la validation et la vérification est une bonne perspective ici : Selenium vérifie l'expérience rendue, tandis que les tests d'API valident le contrat sous-jacent.
Ce que "tester une API avec Selenium" signifie réellement
Lorsque des articles affirment que Selenium peut tester des API, ils signifient généralement l'une des deux solutions de contournement. Aucune des deux ne fait de Selenium un outil de test d'API. Elles ne font qu'acheminer le HTTP à travers ou à côté de lui.
Option un : utiliser l'exécuteur JavaScript de Selenium. Selenium peut exécuter n'importe quel JavaScript arbitraire dans le navigateur qu'il contrôle. Les navigateurs modernes disposent de l'API fetch, vous pouvez donc demander au navigateur d'effectuer une requête et de renvoyer le résultat à votre code de test :
JavascriptExecutor js = (JavascriptExecutor) driver;
Object status = js.executeAsyncScript(
"const callback = arguments[arguments.length - 1];" +
"fetch('https://jsonplaceholder.typicode.com/users/1')" +
" .then(r => callback(r.status))" +
" .catch(e => callback('error: ' + e));"
);
System.out.println("Status code: " + status);
Cela fonctionne. Cela signifie aussi que vous avez démarré un navigateur, un WebDriver et un pont JavaScript purement pour effectuer un appel HTTP qu'un client HTTP normal ferait directement. Vous héritez également des contraintes du navigateur comme CORS, auxquelles un test d'API de serveur à serveur n'a jamais à penser.
Option deux : ignorer Selenium et utiliser une vraie bibliothèque HTTP à côté. Dans un projet Java, cela signifie associer Selenium à REST Assured pour les parties API :
import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;
given()
.when()
.get("https://jsonplaceholder.typicode.com/users/1")
.then()
.statusCode(200)
.body("email", equalTo("Sincere@april.biz"));
Notez que le test API réel est ici entièrement effectué par REST Assured. Selenium n'y contribue en rien. Les deux bibliothèques se trouvent simplement dans le même projet. C'est bien, mais ce n'est pas "tester l'API avec Selenium". C'est tester l'API avec une bibliothèque de test API appropriée, avec Selenium présent pour des tests d'interface utilisateur non liés.
Quand les mélanger est raisonnable
Il existe un cas légitime pour le travail HTTP au sein d'une suite Selenium, et il convient d'être clair à ce sujet. Les tests d'interface utilisateur Selenium nécessitent souvent une configuration ou une désactivation plus rapide via l'API qu'à travers le navigateur.
Imaginons que vous ayez un test d'interface utilisateur qui vérifie la page d'historique des commandes. Pour le tester, une commande doit exister. Cliquer sur l'ensemble du processus de paiement dans le navigateur juste pour créer cette commande est lent et fragile. Au lieu de cela, votre test effectue un appel API direct pour créer la commande, puis utilise Selenium uniquement pour la partie qui nécessite véritablement un navigateur : charger la page d'historique et vérifier que la commande apparaît.
C'est une bonne pratique. L'appel API est un moyen d'atteindre une fin, pas l'objet du test. L'appel API doit toujours passer par un vrai client HTTP, et non par l'exécuteur JavaScript. Donc, même dans ce cas, Selenium ne fait pas le test API. Il fait le test de l'interface utilisateur, et un client HTTP approprié gère la partie API.
Ce modèle de configuration via API est suffisamment courant pour que la plupart des suites de tests matures l'adoptent délibérément. Il maintient la partie lente et pilotée par le navigateur de la suite aussi petite que possible, réservée à la poignée de parcours qui nécessitent véritablement une page rendue. Tout le reste, y compris toute la préparation des données et la majeure partie de la vérification, se fait via des appels HTTP rapides. Le résultat est une suite qui s'exécute en quelques minutes au lieu de plusieurs heures et qui échoue pour de vraies raisons. Pour une vision plus large de la manière dont l'interface utilisateur et les couches automatisées s'articulent, consultez les tests fonctionnels versus les tests automatisés.
Utilisez un outil conçu pour les tests d'API
Si votre objectif est de tester des API, utilisez un outil conçu pour cela. La différence n'est pas minime. Un véritable outil de test d'API vous offre la construction de requêtes, la gestion d'environnements, les assertions sur le statut, les en-têtes et le corps, l'enchaînement de requêtes, les exécutions pilotées par les données et l'intégration CI, sans lancer de navigateur.
Vos options se répartissent en quelques groupes :
| Approche | Idéal pour | Adéquation au test d'API |
|---|---|---|
| Selenium | Tests d'interface utilisateur / tests de bout en bout du navigateur | Faible. Non conçu pour HTTP. |
| REST Assured / requests / supertest | Tests d'API au sein d'un projet de code | Bonne. Vraies bibliothèques HTTP. |
| Postman, Insomnia, Talend API Tester | Tests d'API manuels et scriptés | Bons. Clients spécialement conçus. |
| Apidog | Cycle de vie complet de l'API : conception, débogage, simulation, test, documentation | Forte. Un seul espace de travail pour tout cela. |
Si vous préférez le code, une bibliothèque HTTP comme REST Assured en Java, requests en Python ou supertest en Node est le bon choix. Ces bibliothèques effectuent une requête et vous renvoient la réponse directement, avec des assistants d'assertion intégrés pour les codes de statut et les corps JSON. Il n'y a pas de navigateur, pas de WebDriver et pas de rendu, donc une suite complète s'exécute rapidement et n'échoue que lorsque l'API elle-même change.
Si vous souhaitez un espace de travail visuel, Apidog est une plateforme API tout-en-un qui couvre la conception de l'API, le débogage des requêtes, la simulation des points de terminaison, la création de scénarios de test automatisés et la génération de documentation, le tout dans un seul projet. Vous créez des assertions visuellement ou avec des scripts, enchaînez les requêtes en flux multi-étapes, exécutez des itérations basées sur les données et exécutez tout dans le CI. Il importe également les fichiers OpenAPI et Postman, de sorte qu'une API existante est rapide à intégrer. Rien de tout cela n'implique un navigateur, car rien de tout cela ne le devrait. Vous pouvez télécharger Apidog pour l'essayer sur une API réelle.
Pour les équipes qui préfèrent un framework "code-first", les guides sur Robot Framework pour l'automatisation d'API et la construction d'un framework de test d'automatisation d'API couvrent des approches qui, contrairement à Selenium, sont réellement adaptées aux tests HTTP.
La conclusion honnête
Selenium est un excellent logiciel pour ce pour quoi il a été conçu, c'est-à-dire l'automatisation des navigateurs. Le test d'API n'en fait pas partie. Vous pouvez techniquement faire passer du HTTP via l'exécuteur JavaScript de Selenium, et vous pouvez conserver une bibliothèque HTTP dans le même projet que Selenium, mais dans aucun de ces cas Selenium n'ajoute de valeur au test d'API lui-même.
Choisir le mauvais outil n'est pas une décision neutre. Cela rend vos tests plus lents, plus difficiles à maintenir et sujets à des échecs qui n'ont rien à voir avec votre API. Optez pour un outil conçu pour la tâche. Votre suite de tests sera plus rapide, plus fiable et beaucoup plus facile à comprendre. Le récapitulatif des meilleures plateformes de test automatisé est un bon endroit pour comparer les options conçues à cet effet.
Foire aux questions
Selenium peut-il tester les API REST ?
Il peut émettre des requêtes HTTP via l'exécuteur JavaScript du navigateur, donc dans un sens technique étroit, oui. Mais Selenium n'a aucune fonctionnalité pour inspecter les réponses, faire des assertions sur le JSON ou vérifier les en-têtes, et il supporte toute la surcharge d'un navigateur. Ce n'est pas un outil de test d'API REST, et l'utiliser comme tel crée des tests lents et fragiles.
Pourquoi certains tutoriels montrent-ils Selenium avec REST Assured ?
Parce que les tests d'API dans ces tutoriels sont entièrement effectués par REST Assured, qui est une véritable bibliothèque de test HTTP. Selenium est simplement présent dans le même projet pour des tests d'interface utilisateur non liés. Le jumelage est bien, mais cela ne signifie pas que Selenium teste l'API. C'est REST Assured qui le fait.
Est-il acceptable d'effectuer des appels API dans un test Selenium ?
Oui, pour la configuration (setup) et le nettoyage (teardown). La création de données de test via l'API est plus rapide et plus fiable que de cliquer sur l'interface utilisateur pour les produire. L'appel API prend en charge le test d'interface utilisateur plutôt que d'être l'objet du test, et il doit toujours utiliser un client HTTP approprié, et non l'exécuteur JavaScript de Selenium.
Que devrais-je utiliser à la place de Selenium pour les tests d'API ?
Pour les tests "code-first", une bibliothèque HTTP telle que REST Assured, requests pour Python, ou supertest pour Node. Pour un espace de travail visuel, une plateforme API dédiée comme Apidog, ou des clients comme Postman, Insomnia et Talend API Tester. Tous ces outils sont conçus pour HTTP et évitent la surcharge du navigateur imposée par Selenium.
L'utilisation de Selenium pour les tests API ralentit-elle mon pipeline CI ?
Significativement. Chaque appel API basé sur Selenium démarre un processus de navigateur et une session WebDriver, transformant une requête HTTP de moins d'une seconde en une opération de plusieurs secondes. Sur l'ensemble d'une suite, cela s'ajoute à des exécutions de pipeline longues et fragiles. Un outil de test d'API dédié exécute les mêmes vérifications beaucoup plus rapidement car il ne lance jamais de navigateur.