Ce que les tests d'API avec Cypress font vraiment bien
La préparation et le nettoyage. Créer via l'API l'état dont un test UI a besoin, au lieu de cliquer à travers cinq écrans. Plus rapide, plus fiable, et c'est le bon usage de cette capacité.
Les assertions inter-couches. Faire une action dans l'interface, puis confirmer que le backend l'a correctement enregistrée. C'est un vrai cas d'usage, et Cypress le gère proprement.
Quelques vérifications d'endpoints. Quand la surface d'API est réduite, tout garder dans la même suite est un compromis raisonnable au profit de la simplicité.
Les quatre problèmes qui arrivent avec le passage à l'échelle
La durée de vie des sessions
Les tokens expirent en plein milieu de la suite et les échecs ressemblent à des bugs du produit.
La logique de rafraîchissement finit écrite à la main dans un fichier de support.
Les valeurs entre les appels
Un identifiant issu d'un appel de création doit parvenir jusqu'à l'appel de suppression, et le chaînage de commandes de Cypress rend cela peu pratique d'un test à l'autre.
On code la valeur en dur, et la suite fonctionne une seule fois.
L'ordre d'exécution
Une vraie couverture d'API est un graphe, alors que les fichiers de test sont une liste. Encoder ce graphe à la main, c'est là que part la maintenance.
Le quatrième est le nettoyage. Les enregistrements s'accumulent, les contraintes d'unicité se déclenchent, et les assertions sur la pagination dérivent à mesure que les données grossissent.
Pourquoi ce ne sont pas vraiment des problèmes de Cypress
Cypress a été conçu autour d'un cycle de vie de test piloté par le navigateur. Tout ce qui précède concerne un état qui vit au-delà d'un test unique et au-delà d'une exécution unique. Vous pouvez tout résoudre dans des fichiers de support, et la solution devient un petit framework que quelqu'un doit maintenir : c'est le coût que personne n'anticipe.
Ce qu'une couche d'API dédiée prend en charge à la place
Quatre choses déterminent si une suite d'API survit à sa première année, quel que soit l'outil que vous utilisez : 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 appelle Auto-Authentication, Dynamic Variables, Dependency Chains et Auto-Cleanup, et la documentation sur les tests d'API en détaille les mécanismes.
Quand le fichier de support devient un framework
Il existe un moment identifiable où une suite d'API à l'intérieur de Cypress cesse d'être quelques requêtes pour devenir de l'infrastructure, et il vaut la peine de le nommer pour que vous puissiez décider délibérément plutôt que de dériver.
Cela commence par une commande de connexion dans le fichier de support. Puis un cache de tokens, parce que se connecter à chaque test est lent. Puis une logique de rafraîchissement, parce que le cache devient obsolète en cours d'exécution. Puis un utilitaire qui stocke les identifiants créés pour que les tests suivants les retrouvent, puis des conventions d'ordre dans les noms de fichiers, puis une tâche de nettoyage qui s'exécute après la suite et qui connaît tout cela.
Aucune de ces étapes n'est une erreur, et chacune est la suite évidente de la précédente. Le résultat est un framework de quelques centaines de lignes, logé dans un répertoire de support, compris par une seule personne, et extérieur au runner sur lequel il a été construit. Reconnaître cette trajectoire tôt, c'est tout l'intérêt de la décrire.
Le découpage qui vaut la peine d'être adopté
Gardez cy.request pour la préparation, le nettoyage et les assertions inter-couches qui ont réellement besoin des deux côtés dans un même test. Déplacez la couverture autonome des endpoints et de l'intégration vers une couche qui traite ces quatre problèmes comme faisant partie de son travail, et non comme vos devoirs à faire.
Les deux suites n'ont pas besoin de se connaître, et toutes deux peuvent s'exécuter depuis le même pipeline.
Le déclencheur compte plus que le mécanisme. Le brancher sur votre événement de déploiement, c'est faire vérifier chaque changement sans que personne ait à le décider ; la GitHub App le fait depuis le tableau de bord, et une étape GitHub Actions le fait depuis votre workflow. Détails dans le dépôt CLI.
Ce que vous cessez de maintenir
Le framework en fichiers de support décrit plus haut, c'est précisément ce que TestSprite remplace. Auto-Authentication gère la durée de vie des sessions. Dynamic Variables transportent un identifiant d'un appel de création jusqu'à l'appel de suppression. Dependency Chains déduisent un ordre sûr à partir de ce dont chaque cas a besoin et de ce qu'il produit. Auto-Cleanup supprime exactement ce que l'exécution a créé, ce qui rend l'exécution parallèle sûre.
La couverture cesse aussi de dépendre de qui a du temps. Les plans sont générés à partir d'une spécification ou d'une passe de découverte sur le service en cours d'exécution, y compris les chemins d'erreur et les valeurs limites que personne n'écrit jamais à la main, puis affinés en langage courant.
Cypress conserve ce qu'il fait bien : la préparation, le nettoyage et les vérifications inter-couches où vous avez réellement besoin du navigateur et de l'API dans un même test. Les deux s'exécutent depuis le même pipeline sans rien savoir l'un de l'autre.
cy.request est-il une mauvaise pratique ?
Pas du tout. C'est le bon outil pour la préparation et pour les vérifications inter-couches. La limite est celle de l'échelle, pas de la justesse.
Peut-on tout garder dans Cypress ?
Vous le pouvez, et vous finirez par maintenir vous-même la gestion des sessions, la capture des valeurs, l'ordre d'exécution et le nettoyage. Rentable sur une petite surface, coûteux au-delà.
Et les tests de composants Cypress ?
Rien de tout cela ne les concerne. Les tests de composants répondent à une autre question et il vaut mieux les laisser où ils sont.
Comment éviter une couverture en double ?
Répartissez par question. Cypress répond à la question de savoir si le parcours visible par l'utilisateur fonctionne. La couche d'API répond à celle du comportement des endpoints. Si un test passerait aux deux endroits, il a sa place dans le moins coûteux.
La couche d'API a-t-elle besoin de notre code source ?
Non. Elle travaille sur le service en cours d'exécution, en s'appuyant sur une spécification ou une passe de découverte pour savoir ce qui existe.
Gardez cy.request pour la préparation, pas pour toute la suite d'API.
Les tests d'API avec Cypress sont excellents pour les fixtures et les assertions inter-couches. Dès que la couverture d'API autonome grandit, les sessions, les valeurs capturées, l'ordre d'exécution et le nettoyage se transforment en un framework que vous maintenez à la main : c'est le moment de déplacer cette couche vers un outil conçu pour elle.