Aperçu de 1 000 pieds de l'écriture de tests Cypress #frontend@twiliosendgrid

Publié: 2020-10-03

Chez Twilio SendGrid, nous avons écrit des centaines de tests Cypress de bout en bout (E2E) et continuons d'en écrire davantage à mesure que de nouvelles fonctionnalités sont publiées dans différentes applications Web et équipes. Ces tests couvrent l'ensemble de la pile, vérifiant que les cas d'utilisation les plus courants rencontrés par un client fonctionnent toujours après avoir poussé de nouvelles modifications de code dans nos applications.

Si vous souhaitez d'abord prendre du recul et en savoir plus sur la manière de penser aux tests E2E en général, n'hésitez pas à consulter cet article de blog et à y revenir une fois que vous serez prêt. Cet article de blog ne vous oblige pas à être un expert des tests E2E, mais il aide à se mettre dans le bon état d'esprit car vous verrez pourquoi nous avons fait les choses d'une certaine manière dans nos tests. Si vous recherchez un didacticiel plus détaillé vous présentant les tests Cypress, nous vous recommandons de consulter la documentation Cypress . Dans cet article de blog, nous supposons que vous avez peut-être déjà vu ou écrit de nombreux tests Cypress et que vous êtes curieux de voir comment d'autres écrivent des tests Cypress pour leurs propres applications.

Après avoir écrit de nombreux tests Cypress, vous commencerez à vous remarquer en utilisant des fonctions, des assertions et des modèles Cypress similaires pour accomplir ce dont vous avez besoin. Nous vous montrerons les parties et les stratégies les plus courantes que nous avons utilisées ou réalisées auparavant avec Cypress pour écrire des tests dans des environnements distincts tels que le développement ou la mise en scène. Nous espérons que cet aperçu de 1 000 pieds de la façon dont nous écrivons les tests Cypress vous donnera des idées à comparer avec les vôtres et vous aidera à améliorer votre approche des tests Cypress.

Présenter:

  1. Tour d'horizon de l'API Cypress
  2. Interagir avec les éléments
  3. S'affirmer sur des éléments
  4. Gérer les API et les services
  5. Faire des requêtes HTTP avec cy.request(…)
  6. Créer des plugins réutilisables avec cy.task()
  7. Se moquer des requêtes réseau avec cy.server() et cy.route()
  8. Commandes personnalisées
  9. À propos des objets de page
  10. Choisir de ne pas exécuter de code côté client avec window.Cypress vérifie
  11. Gérer les iframes
  12. Standardisation dans les environnements de test

Tour d'horizon de l'API Cypress

Commençons par passer en revue les parties que nous avons le plus couramment utilisées avec l'API Cypress.

Sélection d'éléments

Il existe de nombreuses façons de sélectionner des éléments DOM, mais vous pouvez accomplir la plupart de ce que vous devez faire via ces commandes Cypress et vous pouvez généralement enchaîner plus d'actions et d'assertions après celles-ci.

  • Obtenir des éléments basés sur un sélecteur CSS avec cy.get(“[data-hook='someSelector']”) ou cy.find(“.selector”) .
  • Sélection d'éléments basés sur du texte tel que cy.contains(“someText”) ou obtention d'un élément avec un certain sélecteur contenant du texte tel que cy.contains(“.selector”, “someText”) .
  • Faire en sorte qu'un élément parent regarde "à l'intérieur", de sorte que toutes vos futures requêtes seront étendues aux enfants du parent, comme cy.get(“.selector”).within(() => { cy.get(“.child”) }) .
  • Trouver une liste d'éléments et parcourir "chacun" pour effectuer plus de requêtes et d'assertions telles que cy.get(“tr”).each(($tableRow) => { cy.wrap($tableRow).find('td').eq(1).should(“contain”, “someText” }) .
  • Parfois, des éléments peuvent être hors de vue de la page, vous devrez donc d'abord faire défiler l'élément dans la vue, comme cy.get(“.buttonFarBelow”).scrollIntoView() .
  • Parfois, vous aurez besoin d'un délai d'expiration plus long que le délai d'expiration de la commande par défaut, vous pouvez donc éventuellement ajouter un { timeout: timeoutInMs } comme cy.get(“.someElement”, { timeout: 10000 }) .

Interagir avec les éléments

Ce sont les interactions les plus utilisées trouvées dans nos tests Cypress. Parfois, vous devrez ajouter une propriété { force: true } dans ces appels de fonction pour contourner certaines vérifications avec les éléments. Cela se produit souvent lorsqu'un élément est couvert d'une manière ou d'une autre ou dérivé d'une bibliothèque externe sur laquelle vous n'avez pas beaucoup de contrôle en termes de rendu des éléments.

  • Nous devons cliquer sur de nombreuses choses telles que les boutons dans les modaux, les tableaux, etc., nous faisons donc des choses comme cy.get(“.button”).click() .
  • Les formulaires sont partout dans nos applications Web pour remplir les détails de l'utilisateur et d'autres champs de données. Nous tapons dans ces entrées avec cy.get(“input”).type(“somekeyboardtyping”) et nous devrons peut-être effacer certaines valeurs par défaut des entrées en les effaçant d'abord comme cy.get(“input”).clear().type(“somenewinput”) . Il existe également des façons intéressantes de taper d'autres touches comme {enter} pour la touche Entrée lorsque vous faites cy.get(“input”).type(“text{enter}”) .
  • Nous pouvons interagir avec des options de sélection comme cy.get(“select”).select(“value”) et des cases à cocher comme cy.get(“.checkbox”).check() .

S'affirmer sur des éléments

Ce sont les assertions typiques que vous pouvez utiliser dans vos tests Cypress pour déterminer si des éléments sont présents sur la page avec le bon contenu.

  • Pour vérifier si des éléments apparaissent ou non sur la page, vous pouvez basculer entre cy.get(“.selector”).should(“be.visible”) et cy.get(“.selector”).should(“not.be.visible”) .
  • Pour déterminer si des éléments DOM existent quelque part dans le balisage et si vous ne vous souciez pas nécessairement de savoir si les éléments sont visibles, vous pouvez utiliser cy.get(“.element”).should(“exist”) ou cy.get(“.element”).should(“not.exist”) .
  • Pour voir si un élément contient ou ne contient pas de texte, vous pouvez choisir entre cy.get(“button”).should(“contain”, “someText”) et cy.get(“button”).should(“not.contain”, “someText”) .
  • Pour vérifier qu'une entrée ou un bouton est désactivé ou activé, vous pouvez affirmer comme ceci : cy.get(“button”).should(“be.disabled”) .
  • Pour affirmer si quelque chose est coché, vous pouvez tester comme, cy.get(“.checkbox”).should(“be.checked”) .
  • Vous pouvez généralement vous fier à des vérifications de texte et de visibilité plus tangibles, mais parfois vous devez vous fier à des vérifications de classe comme cy.get(“element”).should(“have.class”, “class-name”) . Il existe d'autres façons similaires de tester les attributs avec .should(“have.attr”, “attribute”) .
  • Il est souvent utile pour vous de chaîner des assertions comme, cy.get(“div”).should(“be.visible”).and(“contain”, “text”) .

Gérer les API et les services

Lorsque vous traitez avec vos propres API et services liés à la messagerie, vous pouvez utiliser cy.request(...) pour envoyer des requêtes HTTP à vos points de terminaison backend avec des en-têtes d'authentification. Une autre alternative est que vous pouvez créer des cy.task(...) qui peuvent être appelés à partir de n'importe quel fichier de spécification pour couvrir d'autres fonctionnalités qui peuvent être mieux gérées dans un serveur Node avec d'autres bibliothèques telles que la connexion à une boîte de réception et la recherche d'un faire correspondre les e-mails ou avoir plus de contrôle sur les réponses et l'interrogation de certains appels d'API avant de renvoyer certaines valeurs pour les tests à utiliser.

Faire des requêtes HTTP avec cy.request(…)

Vous pouvez utiliser cy.request() pour envoyer des requêtes HTTP à votre API backend afin de configurer ou de supprimer des données avant l'exécution de vos cas de test. Vous transmettez généralement l'URL du point de terminaison, une méthode HTTP telle que "GET" ou "POST", des en-têtes et parfois un corps de requête à envoyer à l'API backend. Vous pouvez ensuite enchaîner cela avec un .then((response) => { }) pour accéder à la réponse du réseau via des propriétés telles que "status" et "body". Un exemple d'appel à cy.request() est présenté ici.

Parfois, vous ne vous souciez peut-être pas de savoir si oui ou non cy.request(...) échouera avec un code d'état 4xx ou 5xx lors du nettoyage avant l'exécution d'un test. Un scénario dans lequel vous pouvez choisir d'ignorer le code d'état d'échec est lorsque votre test effectue une requête GET pour vérifier si un élément existe toujours et a déjà été supprimé. L'élément peut déjà être nettoyé et la requête GET échouera avec un code d'état 404 introuvable. Dans ce cas, vous définiriez une autre option de failOnStatusCode: false afin que vos tests Cypress n'échouent pas avant même d'avoir exécuté les étapes de test.

Créer des plugins réutilisables avec cy.task()

Lorsque nous voulons avoir plus de flexibilité et de contrôle sur une fonction réutilisable pour parler à un autre service tel qu'un fournisseur de boîte de réception via un serveur Node (nous couvrirons cet exemple dans un article de blog ultérieur), nous aimons fournir notre propre fonctionnalité supplémentaire et des réponses personnalisées aux appels d'API que nous devons enchaîner et appliquer dans nos tests Cypress. Ou, nous aimons exécuter un autre code dans un serveur Node - nous construisons souvent un plugin cy.task() pour cela. Nous créons des fonctions de plugin dans les fichiers de module et les importons dans le plugins/index.ts où nous définissons les plugins de tâche avec les arguments dont nous avons besoin pour exécuter les fonctions comme indiqué ci-dessous.

Ces plugins peuvent être appelés avec un cy.task(“pluginName”, { ...args }) n'importe où dans vos fichiers de spécifications et vous pouvez vous attendre à ce que la même fonctionnalité se produise. Alors que, si vous avez utilisé cy.request() , vous avez moins de réutilisabilité à moins que vous n'ayez enveloppé ces appels eux-mêmes dans des objets de page ou des fichiers d'aide à importer partout.

Une autre mise en garde est que, puisque le code de la tâche du plug-in est destiné à être exécuté sur un serveur Node, vous ne pouvez pas appeler les commandes Cypress habituelles dans ces fonctions telles que Cypress.env(“apiHost”) ou cy.getCookie('auth_token') . Vous transmettez des éléments tels que la chaîne de jeton d'authentification ou l'hôte de l'API backend à l'objet d'argument de votre fonction de plug-in en plus des éléments requis pour le corps de la requête s'il doit communiquer avec votre API backend.

Se moquer des requêtes réseau avec cy.server() et cy.route()

Pour les tests Cypress nécessitant des données difficiles à reproduire (comme les variations d'états importants de l'interface utilisateur sur une page ou le traitement d'appels d'API plus lents), une fonctionnalité Cypress à prendre en compte consiste à supprimer les requêtes réseau. Cela fonctionne bien avec les requêtes basées sur XmlHttpRequest (XHR) si vous utilisez vanilla XMLHttpRequest, la bibliothèque axios ou jQuery AJAX. Vous utiliserez ensuite cy.server() et cy.route() pour écouter les routes afin de simuler les réponses pour n'importe quel état souhaité. Voici un exemple :

Un autre cas d'utilisation consiste à utiliser cy.server() , cy.route() et cy.wait() ensemble pour écouter et attendre que les requêtes réseau se terminent avant de passer aux étapes suivantes. Habituellement, après avoir chargé une page ou effectué une sorte d'action sur la page, un signal visuel intuitif signalera que quelque chose est terminé ou prêt à être affirmé et à agir. Pour les cas où vous n'avez pas un signal aussi visible, vous pouvez explicitement attendre qu'un appel d'API se termine comme ceci.

Un gros problème est que si vous utilisez fetch pour les requêtes réseau, vous ne pourrez pas simuler les requêtes réseau ou attendre qu'elles se terminent de la même manière. Vous aurez besoin d'une solution de contournement pour remplacer le window.fetch normal par un polyfill XHR et effectuer quelques étapes de configuration et de nettoyage avant que vos tests ne s'exécutent comme indiqué dans ces problèmes . Il existe également une propriété experimentalFetchPolyfill FetchPolyfill à partir de Cypress 4.9.0 qui peut fonctionner pour vous, mais dans l'ensemble, nous recherchons toujours de meilleures méthodes pour gérer le remplacement du réseau par l'extraction et l'utilisation de XHR dans nos applications sans que les choses ne se cassent. À partir de Cypress 5.1.0, il existe une nouvelle fonction prometteuse cy.route2() (voir la documentation Cypress ) pour le masquage réseau expérimental des requêtes XHR et de récupération, nous prévoyons donc de mettre à niveau notre version Cypress et de l'expérimenter pour voir si cela résout nos problèmes.

Commandes personnalisées

Semblable aux bibliothèques telles que WebdriverIO, vous pouvez créer des commandes personnalisées globales qui peuvent être réutilisées et enchaînées dans vos fichiers de spécifications, comme une commande personnalisée pour gérer les connexions via l'API avant l'exécution de vos cas de test. Une fois que vous les avez développés dans un fichier tel que support/commands.ts , vous pouvez accéder aux fonctions telles que cy.customCommand() ou cy.login() . La rédaction d'une commande personnalisée pour la connexion ressemble à ceci.

À propos des objets de page

Un objet de page est un wrapper autour des sélecteurs et des fonctions pour vous aider à interagir avec une page. Vous n'avez pas besoin de créer des objets de page pour écrire vos tests, mais il est bon d'envisager des moyens d'encapsuler les modifications apportées à l'interface utilisateur. Vous voulez vous faciliter la vie en regroupant les choses pour éviter de mettre à jour les sélecteurs et les interactions dans plusieurs fichiers plutôt qu'à un seul endroit.

Vous pouvez définir une classe "Page" de base avec des fonctionnalités communes telles que open() pour les classes de page héritées à partager et à partir desquelles s'étendre. Les classes de page dérivées définissent leurs propres fonctions getter pour les sélecteurs et autres fonctions d'assistance tout en réutilisant les fonctionnalités des classes de base via des appels tels que super.open() , comme illustré ici.

Choisir de ne pas exécuter de code côté client avec window.Cypress vérifie

Lorsque nous avons testé des flux avec des fichiers à téléchargement automatique tels qu'un fichier CSV, les téléchargements interrompaient souvent nos tests Cypress en gelant l'exécution du test. En guise de compromis, nous voulions principalement tester si l'utilisateur pouvait atteindre l'état de réussite approprié pour un téléchargement et ne pas réellement télécharger le fichier lors de notre test en ajoutant une vérification window.Cypress .

Pendant les tests Cypress, une propriété window.Cypress sera ajoutée au navigateur. Dans votre code côté client, vous pouvez choisir de vérifier s'il n'y a pas de propriété Cypress sur l'objet window, puis effectuez le téléchargement comme d'habitude. Mais, s'il est exécuté dans un test Cypress, ne téléchargez pas réellement le fichier. Nous avons également profité de la vérification de la propriété window.Cypress pour nos expériences A/B exécutées dans notre application Web. Nous ne voulions pas ajouter plus de flakiness et de comportement non déterministe des expériences A/B montrant potentiellement différentes expériences à nos utilisateurs de test, nous avons donc d'abord vérifié que la propriété n'est pas présente avant d'exécuter la logique d'expérience comme indiqué ci-dessous.

Gérer les iframes

La gestion des iframes peut être difficile avec Cypress car il n'y a pas de support iframe intégré. Il y a un [issue]( https://github.com/cypress-io/cypress/issues/136 ) en cours d'exécution rempli de solutions de contournement pour gérer les iframes uniques et les iframes imbriqués, qui peuvent ou non fonctionner selon votre version actuelle de Cypress ou l'iframe avec lequel vous avez l'intention d'interagir. Pour notre cas d'utilisation, nous avions besoin d'un moyen de gérer les iframes de facturation Zuora dans notre environnement intermédiaire pour vérifier les flux de mise à niveau de l'API Email et de l'API Marketing Campaigns. Nos tests impliquent de remplir des exemples d'informations de facturation avant d'effectuer une mise à niveau vers une nouvelle offre dans notre application.

Nous avons créé une commande personnalisée cy.iframe(iframeSelector) pour encapsuler le traitement des iframes. Passer un sélecteur à l'iframe vérifiera alors le contenu du corps de l'iframe jusqu'à ce qu'il ne soit plus vide, puis renverra le contenu du corps pour qu'il soit enchaîné avec plus de commandes Cypress, comme indiqué ci-dessous :

Lorsque vous travaillez avec TypeScript, vous pouvez saisir votre commande personnalisée iframe comme ceci dans votre fichier index.d.ts :

Pour accomplir la partie facturation de nos tests, nous avons utilisé la commande personnalisée iframe pour obtenir le contenu du corps de l'iframe Zuora, puis nous avons sélectionné les éléments dans l'iframe et changé leurs valeurs directement. Nous avions auparavant des problèmes avec l'utilisation de cy.find(...).type(...) et d'autres alternatives qui ne fonctionnaient pas, mais heureusement, nous avons trouvé une solution de contournement en modifiant les valeurs des entrées et en sélectionnant directement avec la commande d'appel, c'est-à-dire cy.get(selector).invoke('val', 'some value') . Vous aurez également besoin ”chromeWebSecurity”: false dans votre fichier de configuration cypress.json pour vous permettre de contourner les erreurs d'origine croisée. Un exemple d'extrait de son utilisation avec les sélecteurs de remplissage est fourni ci-dessous :

Standardisation dans les environnements de test

Après avoir écrit des tests avec Cypress en utilisant les assertions, les fonctions et les approches les plus courantes décrites précédemment, nous sommes en mesure d'exécuter les tests et de les faire passer dans un environnement. C'est une excellente première étape, mais nous avons plusieurs environnements pour déployer un nouveau code et tester nos modifications. Chaque environnement a son propre ensemble de bases de données, de serveurs et d'utilisateurs, mais nos tests Cypress ne doivent être écrits qu'une seule fois pour fonctionner avec les mêmes étapes générales.

Afin d'exécuter des tests Cypress sur plusieurs environnements de test tels que le développement, les tests et la mise en scène avant de déployer éventuellement nos modifications en production, nous devons tirer parti de la capacité de Cypress à ajouter des variables d'environnement et à modifier les valeurs de configuration pour prendre en charge ces cas d'utilisation.

Pour exécuter vos tests sur différents environnements frontaux :

Vous devrez modifier la valeur "baseUrl" accessible via Cypress.config(“baseUrl”) pour qu'elle corresponde à ces URL telles que https://staging.app.com ou https://testing.app.com . Cela modifie l'URL de base pour tous vos cy.visit(...) ajouter leurs chemins. Il existe plusieurs façons de le définir, par exemple en définissant CYPRESS_BASE_URL=<frontend_url> avant d'exécuter votre commande Cypress ou en définissant --config baseUrl=<frontend_url> .

Pour exécuter vos tests sur différents environnements backend :

Vous devez connaître le nom d'hôte de l'API tel que https://staging.api.com ou https://testing.api.com pour le définir dans une variable d'environnement telle que "apiHost" et accessible via des appels tels que Cypress.env(“apiHost”) . Ceux-ci seront utilisés pour vos cy.request(...) pour faire des requêtes HTTP à certains chemins comme "<apiHost>/some/endpoint" ou transmis à vos appels de fonction cy.task(...) comme un autre argument propriété pour savoir quel backend frapper. Ces appels authentifiés auraient également besoin de connaître le jeton d'authentification que vous stockez probablement dans localStorage ou un cookie via cy.getCookie(“auth_token”) . Assurez-vous que ce jeton d'authentification est finalement transmis dans le cadre de l'en-tête "Autorisation" ou par d'autres moyens dans le cadre de votre demande. Il existe une multitude de façons de définir ces variables d'environnement, par exemple directement dans le fichier cypress.json ou dans les options de ligne de commande --env où vous pouvez les référencer dans la documentation Cypress .

Pour aborder la connexion à différents utilisateurs ou l'utilisation de différentes métadonnées :

Maintenant que vous savez comment gérer plusieurs URL frontales et hôtes d'API backend, comment gérez-vous la connexion à différents utilisateurs ? Comment utilisez-vous des métadonnées variables en fonction de l'environnement, telles que des éléments liés aux domaines, aux clés d'API et à d'autres ressources susceptibles d'être uniques dans les environnements de test ?

Commençons par créer une autre variable d'environnement appelée "testEnv" avec des valeurs possibles de "testing" et "staging" afin que vous puissiez l'utiliser comme un moyen de dire quels utilisateurs et métadonnées d'environnement appliquer dans le test. En utilisant la variable d'environnement "testEnv", vous pouvez aborder cela de plusieurs manières.

Vous pouvez créer des fichiers « staging.json », « testing.json » et d'autres fichiers JSON d'environnement séparés dans le dossier des fixtures et les importer pour que vous les utilisiez en fonction de la valeur « testEnv », telle que cy.fixture(`${testEnv}.json`).then(...) . Cependant, vous ne pouvez pas bien taper les fichiers JSON et il y a beaucoup plus de place pour les erreurs de syntaxe et d'écriture de toutes les propriétés requises par test. Les fichiers JSON sont également plus éloignés du code de test, vous devrez donc gérer au moins deux fichiers lors de la modification des tests. Des problèmes de maintenance similaires se produiraient si toutes les données de test d'environnement étaient définies dans des variables d'environnement directement dans votre cypress.json et il y en aurait trop à gérer sur une pléthore de tests.

Une autre option consiste à créer un objet de montage de test dans le fichier de spécifications avec des propriétés basées sur les tests ou la mise en scène pour charger l'utilisateur et les métadonnées de ce test pour un certain environnement. Puisqu'il s'agit d'objets, vous pouvez également définir un meilleur type TypeScript générique autour des objets de montage de test pour tous vos fichiers de spécifications à réutiliser et pour définir les types de métadonnées. Vous appelleriez Cypress.env(“testEnv”) pour voir sur quel environnement de test vous exécutez et utiliser cette valeur pour extraire le montage de test de l'environnement correspondant de l'objet global de montage de test et utiliser ces valeurs dans votre test. L'idée générale de l'objet test fixtures est résumée dans l'extrait de code ci-dessous.

L'application de la valeur de configuration Cypress "baseUrl", de la variable d'environnement backend "apiHost" et de la variable d'environnement "testEnv" nous permet d'avoir des tests Cypress qui fonctionnent sur plusieurs environnements sans ajouter plusieurs conditions ou flux logiques séparés, comme illustré ci-dessous.

Prenons un peu de recul pour voir comment vous pouvez même créer vos propres commandes Cypress pour qu'elles s'exécutent via npm. Des concepts similaires peuvent être appliqués au fil, au Makefile et à d'autres scripts que vous utilisez peut-être pour votre application. Vous pouvez définir des variantes des commandes "open" et "run" pour vous aligner sur "open" de Cypress dans l'interface graphique et "run" en mode sans tête sur divers environnements frontend et backend dans votre package.json . Vous pouvez également configurer plusieurs fichiers JSON pour la configuration de chaque environnement, mais pour plus de simplicité, vous verrez les commandes avec les options et les valeurs en ligne.

Vous remarquerez dans les scripts package.json que votre frontend "baseUrl" va de "http://localhost:9001" pour le démarrage local de votre application à l'URL de l'application déployée telle que " https://staging.app. com ». Vous pouvez définir les variables backend "apiHost" et "testEnv" pour vous aider à envoyer des requêtes à un point de terminaison backend et à charger un objet de montage de test spécifique. Vous pouvez également créer des commandes "cicd" spéciales lorsque vous devez exécuter vos tests dans un conteneur Docker avec la clé d'enregistrement.

Quelques plats à emporter

Lorsqu'il s'agit de sélectionner des éléments, d'interagir avec des éléments et d'affirmer des éléments sur la page, vous pouvez aller assez loin en écrivant de nombreux tests Cypress avec une petite liste de commandes Cypress telles que cy.get() , cy.contains() , .click() , .type() , .should('be.visible') .

Il existe également des moyens de faire des requêtes HTTP à une API backend à l'aide cy.request() , d'exécuter du code arbitraire dans un serveur Node avec cy.task() et de supprimer les requêtes réseau à l'aide cy.server() et cy.route() . Vous pouvez même créer votre propre commande personnalisée comme cy.login() pour vous aider à vous connecter à un utilisateur via l'API. Toutes ces choses aident à réinitialiser un utilisateur au bon point de départ avant l'exécution des tests. Enveloppez ces sélecteurs et ces fonctions dans un fichier et vous avez créé des objets de page réutilisables à utiliser dans vos spécifications.

Pour vous aider à écrire des tests qui réussissent dans plusieurs environnements, tirez parti des variables d'environnement et des objets contenant des métadonnées spécifiques à l'environnement.

Cela vous aidera à exécuter différents ensembles d'utilisateurs avec des ressources de données distinctes dans vos spécifications Cypress. Des commandes Cypress npm distinctes telles que npm run cypress:open:staging dans votre package.json chargeront les valeurs de variable d'environnement appropriées et exécuteront les tests pour l'environnement que vous avez choisi d'exécuter.

Ceci conclut notre aperçu de mille pieds de l'écriture des tests Cypress. Nous espérons que cela vous a fourni des exemples pratiques et des modèles à appliquer et à améliorer dans vos propres tests Cypress.

Vous souhaitez en savoir plus sur les tests Cypress ? Consultez les ressources suivantes :

  • Éléments à prendre en compte lors de la rédaction de tests E2E
  • TypeScript Toutes les choses dans vos tests Cypress
  • Gestion des flux de messagerie dans les tests Cypress
  • Idées pour configurer, organiser et consolider vos tests Cypress
  • Intégration des tests Cypress avec Docker, Buildkite et CICD