Pourquoi la question des tests d'API avec Selenium se pose
Trois raisons, dont une seule est valable.
La suite existe déjà. Il y a un job Selenium dans la CI, les équipes savent le lancer, et y ajouter des vérifications d'API est la voie de moindre résistance. C'est compréhensible, mais la raison est organisationnelle, pas technique.
Le parcours couvre les deux. Soumettre un formulaire, puis vérifier que l'enregistrement créé par l'API est correct. Ce cas-là est légitime, et c'est celui qui mérite d'être conçu pour.
Préparation et nettoyage. Créer des jeux de données via l'API parce que passer par l'interface est trop lent. C'est raisonnable, même si cela relève de la tuyauterie plutôt que du test.
Ce que cela coûte
| Des retours lents | Le démarrage du navigateur domine une vérification qui aurait pu être une simple requête. Une suite qui prend vingt minutes est lancée moins souvent, et c'est là la véritable perte. |
| Des échecs confus | Quand un test combiné échoue, vous devez déterminer si c'est l'interface ou l'API qui a lâché. Des suites séparées vous donnent cette réponse gratuitement. |
| Une couverture dictée par l'UI | Vous finissez par couvrir les endpoints que l'interface appelle, soit une fraction de la surface. Les codes d'erreur et les paramètres limites ne sont jamais exercés. |
La répartition qui fonctionne
Gardez Selenium pour ce que seul un navigateur peut trancher : le parcours visible par l'utilisateur fonctionne-t-il. Couvrez l'API à son propre niveau, là où une vérification est une requête et non un chargement de page. Depuis la suite Selenium, n'utilisez l'API que pour la préparation et le nettoyage, là où seule la vitesse compte et où aucune assertion n'intervient.
Le seul cas réellement transversal, soumettre un formulaire et vérifier ce que le backend a enregistré, mérite d'être écrit délibérément plutôt que par accident. Cela représente un petit nombre de tests, et ils justifient leur coût.
Ce qu'une couche d'API autonome doit gérer
Quatre éléments déterminent si une suite d'API survit à sa première année, quel que soit l'outil utilisé : 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 nomme Auto-Authentication, Dynamic Variables, Dependency Chains et Auto-Cleanup, et la documentation sur les tests d'API en détaille les mécanismes.
Bien traiter ces quatre points, c'est ce qui distingue une suite qui dure d'une suite supprimée au bout de deux trimestres, et c'est bien plus simple à faire au niveau de l'API que greffé sur une suite navigateur.
La préparation, faite correctement
Utiliser l'API pour créer les jeux de données d'un test navigateur est le seul endroit où ces deux mondes ont vraiment leur place ensemble, et cela mérite d'être fait délibérément plutôt que par accident.
La règle qui garde l'ensemble propre, c'est que les appels de préparation ne font jamais d'assertion. Leur rôle est de placer le système dans un état connu le plus vite possible, et si l'un d'eux échoue, le test doit sortir en erreur plutôt qu'en échec, car un jeu de données non créé est un problème d'infrastructure et non un défaut du produit. Confondre les deux produit une suite où la moitié du rouge n'est que du bruit.
La deuxième règle, c'est que tout ce que la préparation a créé, le nettoyage le supprime, en le rattachant au test concerné plutôt qu'en le retrouvant par son nom. Les suites navigateur accumulent des données plus vite que prévu, et une vue en liste qui ralentit chaque semaine, c'est généralement un nettoyage qui n'a jamais été écrit.
Faire tourner les deux
Aucune des deux suites n'a besoin de connaître l'autre. Selenium s'exécute dans votre job de CI comme aujourd'hui, et la couverture d'API s'exécute à côté.
Si le pipeline appartient à une autre équipe, la GitHub App est la voie de moindre résistance : c'est un webhook, elle ne change rien dans votre dépôt, et elle se déclenche quand votre build signale la mise en ligne de la nouvelle version. Si vous préférez que la vérification soit visible dans le dépôt, une étape GitHub Actions s'en charge. Voir le dépôt du CLI.
Ce que TestSprite couvre au niveau de l'API
TestSprite prend en charge la couche d'API autonome pour que vous n'ayez pas à la greffer sur une suite navigateur. API Discovery recense ce que le service en cours d'exécution expose, la génération de plan propose des cas couvrant les catégories fonctionnelle, schéma, autorisation, gestion des erreurs et valeurs limites, et vous les affinez en langage naturel.
Les quatre problèmes d'état sont pris en charge par le produit plutôt que par votre infrastructure : Auto-Authentication maintient les sessions actives, Dynamic Variables transporte les valeurs d'un appel à l'autre, Dependency Chains déduit l'ordre d'exécution, Auto-Cleanup supprime ce qu'une exécution a créé. Ce sont ces points qui rendent une suite d'API difficile à maintenir en vie, et ils sont bien plus simples à résoudre au niveau de l'API qu'à l'intérieur d'un runner de navigateur.
Votre suite Selenium reste où elle est, et couvre ce que seul un navigateur peut trancher. Les deux s'exécutent depuis le même pipeline.
Selenium peut-il envoyer directement des requêtes HTTP ?
Via les bindings du langage, oui, puisque vous écrivez simplement du code. La question est de savoir si une session de navigateur doit intervenir, et pour une vérification purement API, la réponse est généralement non.
Faut-il migrer notre suite Selenium ?
Pas en bloc. Une suite Selenium à laquelle les équipes font confiance est un atout. Ajoutez la couverture d'API à son propre niveau plutôt que de déplacer quoi que ce soit.
Comment tester un parcours qui couvre les deux ?
Écrivez-le délibérément comme un seul test, gardez-en un nombre réduit, et rendez l'assertion assez précise pour qu'un échec vous dise quel côté a lâché.
Playwright est-il meilleur pour cela ?
Il dispose d'une API de requêtes de premier ordre, donc la mécanique est plus agréable. L'argument architectural, lui, reste le même : les vérifications navigateur et les vérifications d'API répondent à des questions différentes et gagnent à rester séparées.
Et l'authentification commune aux deux ?
Partagez la source des identifiants, pas la session. Chaque couche doit obtenir sa propre session, pour qu'une défaillance de l'une ne se propage pas à l'autre.
Utilisez le navigateur pour les questions de navigateur.
Les tests d'API avec Selenium consistent généralement à coordonner deux types de vérification plutôt qu'à forcer un seul outil à faire les deux. Gardez Selenium pour les parcours visibles par l'utilisateur, couvrez l'API à son propre niveau, et écrivez délibérément les tests réellement transversaux.