Plongeons dans Cypress pour des tests de bout en bout

Le test de bout en bout est-il un sujet douloureux pour vous ? Dans cet article, Ramona Schwering explique comment gérer les tests de bout en bout avec Cypress et les rendre moins fastidieux et coûteux pour vous-même, mais plutôt amusants.

Le développement de logiciels sans tests automatisés est difficile à imaginer aujourd'hui. Une bonne variété de procédures de test différentes garantira un haut niveau de qualité. Comme base pour les tests, nous pouvons utiliser un certain nombre de tests unitaires. En plus de cela, au milieu de la pyramide, pour ainsi dire, se trouvent les tests d'intégration. Les tests de bout en bout sont au sommet, couvrant les cas d'utilisation les plus critiques. Ce troisième type de test sera au centre de cet article.

Cependant, les tests de bout en bout présentent certains pièges qui sont préoccupants :

• Les tests de bout en bout sont lente et, par conséquent, constitue un obstacle important dans toute stratégie d'intégration continue et de déploiement continu (CI/CD). Non seulement cela, mais imaginez terminer une tâche, une fonctionnalité ou toute autre implémentation – attendre que le test s'exécute peut épuiser la patience de tout le monde.
• De tels tests de bout en bout sont difficiles à maintenir, sujets aux erreurs et coûteux. de toutes les manières en raison de l'effort de débogage. Divers facteurs peuvent provoquer cela. Votre test doit ressembler à un assistant, jamais à un obstacle.
• Le plus grand cauchemar pour les développeurs est un test floconneuxqui est un test exécuté de la même manière mais aboutissant à des résultats différents. C'est comme un "Heisenbug", qui ne se produit que si vous ne mesurez pas l'application testée, c'est-à-dire si vous ne la regardez pas.

Mais ne vous inquiétez pas : vous n'êtes pas obligé de succomber à ces pièges. Voyons comment éviter bon nombre d'entre eux . Cependant, je ne vais pas simplement promettre la lune et ne pas livrer. Dans ce guide, nous écrirons ensemble quelques tests, que j'ai rendus publics pour vous dans un dépôt GitHub. De cette façon, j'espère vous montrer que les tests finaux peuvent être amusants ! Commençons.

Que sont les tests de bout en bout ?

Quand je parle de tests de bout en bout (ou E2E), j'aime les qualifier de « basés sur les flux de travail ». La phrase résume bien les tests de bout en bout : elle simule les flux de travail réels des utilisateurs et doit inclure autant de domaines fonctionnels et de parties de la pile technologique utilisée dans l'application que possible. Au final, l'ordinateur se fait passer pour un client et essaie de se comporter comme un vrai utilisateur. Ces tests sont les meilleurs pour appliquer une contrainte constante à l'ensemble du système de votre application et, par conséquent, sont une excellente mesure pour garantir la qualité lorsque toute la pile d'applications est présente.

Rappelons ce que nous voulons réaliser avec tout cela. Nous savons que les tests frontaux sont un ensemble de pratiques permettant de tester l'interface utilisateur d'une application Web, y compris ses fonctionnalités. C'est logique — avec ces mesures, nous pouvons nous assurer que notre application fonctionne correctement et qu'aucune modification future ne brisera notre code. Pour y parvenir efficacement, vous vous demandez peut-être quoi et combien vous devez tester.

C'est une question valable. Vous pourriez trouver une réponse possible dans une métaphore : la pyramide d'automatisation des testsintroduite pour la première fois par Mike Cohn et précisée par Martin Fowler, montre comment rendre les tests efficaces. Nous trouvons des tests unitaires rapides et bon marché au niveau le plus bas de la pyramide, et des tests d'interface utilisateur longs et coûteux (tests de bout en bout) au sommet.

Expliquer cela et ses avantages et inconvénients suffirait pour son propre article. J'aimerais me concentrer sur un seul niveau. Les tests de bout en bout en particulier peuvent apporter des améliorations significatives de la qualité s'ils sont priorisés de manière efficace. Ce faisant, nous pouvons constamment mettre notre système sous tension et nous assurer que les principales fonctions de notre application fonctionnent correctement.

My Journey To Cypress

Quand j'ai commencé à apprendre à écrire des tests de bout en bout, j'ai utilisé Minkune bibliothèque PHP, sur top of Behatun cadre de développement axé sur le comportement (BDD) orienté scénario. J'ai commencé à utiliser Seleniumavec tous ses avantages et inconvénients. Comme mon équipe avait beaucoup commencé à travailler avec Vue.jsnous sommes passés à un framework de test basé sur JavaScript pour assurer une intégration et une compatibilité sans faille. Notre choix à l'époque était Nightwatch.jsj'ai donc construit notre nouvelle suite de tests à partir de zéro.

Pendant ce temps, nous avons souvent trébuché sur des problèmes de compatibilité. Vous pourriez l'appeler l'enfer de la dépendance – sans parler de toutes les limitations que nous avons vues avec Selenium et plus tard avec WebDriver.

• Dans notre équipe, nous n'avons pas pu cerner la version Chrome de notre CI. Ainsi, si des mises à jour de Chrome étaient publiées, Nightwatch.js n'était pas assez rapide pour être compatible, provoquant de nombreux échecs dans nos pipelines de test. Nightwatch.js ne correspondait pas de manière optimale à notre produit.

Nous avons donc envisagé de recréer notre suite de tests. Après avoir visité une non-conférence, j'ai découvert Cypress.

Cypress est un framework de test tout-en-un qui n'utilise ni Selenium ni WebDriver. L'outil utilise Node.js pour démarrer un navigateur sous un contrôle spécial. Les tests dans ce cadre sont exécutés au niveau du navigateur, pas seulement au niveau du contrôle à distance. Cela offre plusieurs avantages.

En bref, voici les raisons pour lesquelles j'ai choisi ce framework :

• Excellente capacité de débogage
  Le testeur de Cypress peut revenir à n'importe quel état de l'application via des instantanés. Ainsi, nous pouvons voir directement une erreur et toutes les étapes qui la précèdent. De plus, il y a un accès complet aux outils de développement de Chrome (DevTools), et les clics sont entièrement enregistrés.
• De meilleures façons d'attendre les actions dans le test ou l'interface utilisateur ou dans les réponses de l'API
  Cypress apporte attente implicite, il n'y a donc pas besoin de vérifications appropriées. Vous pouvez également faire en sorte que le test attende les animations et les réponses de l'API.
• Les tests sont écrits en JavaScript
  Cela atténue la courbe d'apprentissage pour écrire des tests. Le testeur de Cypress est open source, il correspond donc à notre stratégie produit.

Cependant, cet article est un guide, alors arrêtons-nous avec ces informations générales et allons-y.

Mise en route

Installer et démarrer Cypress

Commençons à zéro. Dans mes discussions sur Cypress, je commence généralement par créer un nouveau répertoire via mkdirpuis par installer immédiatement Cypress. La façon la plus simple d'installer est illustrée dans ce dessin :

Un petit indice : si vous ne souhaitez pas utiliser npm, vous pouvez installer Cypress via Yarn :

yarn add cypress --dev

Une alternative est le téléchargement direct, en utilisant les dossiers ZIP fournis par Cypress. C'est ça! Une fois l'installation terminée, vous êtes prêt à commencer.

Il existe deux façons de commencer à exécuter les tests Cypress. La première consiste à démarrer Cypress dans la console et à exécuter vos tests sans la tête :

./node_modules/.bin/cypress run

La deuxième façon consiste à utiliser l'une des fonctionnalités intéressantes de Cypress, qui est son lanceur de test intégré. Le lanceur de test est une interface utilisateur pour exécuter des tests. Pour le lancer, vous pouvez utiliser une commande similaire :

./node_modules/.bin/cypress open

Cette commande ouvrira le lanceur de test. Lorsque vous ouvrez Cypress pour la première fois, vous verrez cette interface :

Cypress fournit des exemples de tests pré-écrits pour présenter ses fonctionnalités et vous donner quelques points de départ – c'est la raison pour laquelle les tests sont disponibles. Ignorons-les pour l'instant, car nous voulons écrire les nôtres bientôt. Cependant, gardez à l'esprit cette zone "Tests d'intégration", car elle représentera une grande partie de la magie qui se produira plus tard.

Première impression de la structure de Cypress

Maintenant, il est temps d'ouvrir notre projet nouvellement créé dans l'environnement de développement intégré (IDE) de votre choix. Si vous accédez à ce dossier, vous verrez la structure de test suivante :

smashing-example
  cyprès
      appareils
      intégration
      plugins
      soutien
  └── cypress.json

Passons en revue ces dossiers :

• fixtures
  C'est ici que vous trouverez des données de test fixes, qui n'ont aucun rapport avec les autres entités. Ainsi, aucun identifiant n'est stocké ici, ce qui peut changer en fonction de l'état local.
• integration
  Vous trouverez les tests réels ici.
• plugins
  Ici, vous pouvez étendre Cypress, que ce soit avec les plugins Cypress existants ou les vôtres.
• support
  Ici, vous pouvez étendre Cypress lui-même. Vos propres commandes et aides se trouvent ici.
• cypress.json
  Modifiez les configurations ici, y compris pour l'environnement.

Très bien, je pense que nous pouvons maintenant trouver notre chemin autour de Cypress, que ce soit le test coureur ou le code source. Mais comment commençons-nous ? Que voulons-nous tester ?

Choisir un scénario de test

Un test de bout en bout typique peut devenir complexe, en particulier s'il comporte de nombreuses étapes. L'exécution manuelle prendrait beaucoup de temps. En raison de cette complexité, les tests E2E peuvent être difficiles à automatiser et lents à exécuter. En conséquence, nous devons soigneusement décider quels cas automatiser.

À mon avis, le terme « basé sur le workflow » est essentiel : nous sélectionnerions des cas de test en fonction des histoires d'utilisateurs typiques. Cependant, en raison des temps d'exécution, il n'est pas conseillé de couvrir tous les flux de travail disponibles. Par conséquent, nous avons besoin d'un moyen de prioriser nos cas de test.

Dans mon équipe, nous avions plusieurs critères pour notre projet. Le scénario de test doit :

• couvrir les workflows les plus généraux et les plus utilisés d'une fonctionnalité, tels que les opérations CRUD (le terme « happy path » décrit assez bien ces workflows) ;
• utiliser l'analyse des risques, couvrant les workflows avec E2E les tests les plus vulnérables (c'est-à-dire là où les erreurs causeraient le plus de dégâts) ;
• évitez la couverture en double ;
• ne pas nécessairement être utilisé si les tests unitaires sont plus appropriés (utilisez un test E2E pour tester la réponse de votre logiciel à une erreur, pas l'erreur elle-même).

La deuxième chose la plus importante à garder à l'esprit est de ne tester que le flux de travail que vous souhaitez explicitement tester. Toutes les autres étapes requises pour que votre test fonctionne doivent être effectuées avec des opérations d'API en dehors du test, pour éviter de les tester. De cette façon, vous garantirez des temps d'exécution de test minimaux et obtiendrez un résultat clair de votre cas de test en cas d'échec. Considérez ce flux de travail comme le ferait un utilisateur final : Concentrez-vous sur l'utilisation de la fonctionnalité plutôt que sur la mise en œuvre technique.

Exemple :

Si vous souhaitez tester le processus de paiement dans une boutique en ligne, ne N'effectuez pas toutes les autres étapes, telles que la création des produits et des catégories, même si vous en aurez besoin pour traiter le paiement. Utilisez, par exemple, une API ou un vidage de base de données pour faire ces choses, et configurez le test uniquement pour le paiement.

Exemple : Trouver mes articles dans Smashing Magazine

Je souhaite écrire un test pour ce site Web, Smashing Magazine. Je ne peux pas garantir que ce test sera à jour pour toujours, mais espérons qu'il durera. Dans tous les cas, vous pourrez trouver cet exemple dans un dépôt GitHub.

Creating Our First Cypress Test

Dans le dossier integrationnous commencerons par création d'un nouveau fichier. Appelons-le find-author.spec.js. Le suffixe .spec signifie « spécification ». En termes de test, il s'agit des détails techniques d'une fonctionnalité ou d'une application donnée que votre application doit remplir.

Pour transformer ce fichier JavaScript vide en un home de test, nous allons commencer par donner sa structure à la suite de tests. Nous utiliserons la méthode appelée describe. describe()ou context()est utilisé pour contenir et organiser les tests. En d'autres termes, cette méthode sert de cadre à nos tests. Ainsi, notre fichier de test ressemblera à ceci :

// find-author.spec.js
describe('Trouver des auteurs à smashing', () => {
  //...
});

L'étape suivante consiste à créer le test réel. Nous utiliserons la méthode it. it()ou specify()est utilisé pour représenter le test réel. Comme vous pouvez le voir, nous pouvons capturer plusieurs tests dans un seul fichier, ce qui permet d'excellentes options de structuration.

// find-author.spec.js
describe('Trouver des auteurs à smashing', () => {
  it('Trouver l'auteur Ramona Schwering', () => {
    cy.log('Ceci est notre tout nouveau test');
  });
});

Petit indice : Si vous connaissez Mokavous avez peut-être remarqué certaines similitudes. Cypress est construit sur Mocha, donc la syntaxe est la même.

Très bien, continuons. Si nous exécutons notre test dans le testeur de Cypress, nous remarquerons que Cypress ouvrira un navigateur pour exécuter le test. Ce navigateur est visible dans la capture d'écran ci-dessous :

Félicitations ! Nous avons écrit notre premier test ! Bien sûr, cela ne fait pas grand-chose. Nous devons continuer. Remplissons notre test de vie.

Remplir le test de vie

Quelle est la première chose à faire lorsque vous testez un site Web ? Bon, nous devons ouvrir le site Web. Nous pouvons le faire en utilisant une commande Cypress. Quelle est la commande, vous demandez-vous peut-être ?

Travailler avec des commandes

Il existe principalement deux types d'instructions utilisées dans un test E2E. Le premier type d'instruction, les commandes, représente les étapes individuelles du test. Dans le contexte de Cypress, les commandes sont tout ce que Cypress fait pour interagir avec votre site Web. Cette interaction peut être n'importe quoi : un clic, un défilement vers le bas du site Web ou même la recherche d'un élément. En conséquence, les commandes seront l'une des choses importantes avec lesquelles nous remplirons notre test.

Ainsi, notre première commande sera celle pour naviguer vers le site Web – smashingmagazine.com . Cette commande s'appelle visit.

En l'utilisant, notre test ressemblera à ceci :

// find-author.spec.js
describe('Trouver des auteurs à smashing', () => {
  it('Trouver l'auteur Ramona Schwering', () => {
    cy.visit('https://www.smashingmagazine.com/');
  });
});

Il y a une commande que j'utilise souvent – et vous l'utiliserez aussi. Elle s'appelle get:

cy.get('selector');

Cette commande renvoie un élément en fonction de son sélecteur — similaire à $(… ). Ainsi, vous utiliseriez cette commande pour trouver les pièces avec lesquelles interagir. Habituellement, vous l'utiliseriez pour démarrer une chaîne de commandes. Mais attendez — qu'entend-on par chaîne de commandes ?

Comme mentionné au début de cet article, tous les tests et tout ce qui les accompagne sont écrits en JavaScript. Vous pouvez mettre les commandes dans les tests (c'est-à-dire les instructions) dans une chain (enchaîné, en d'autres termes). Cela signifie que les commandes peuvent transmettre un sujet (ou une valeur de retour) d'une commande à la commande suivante, comme nous le savons de nombreux frameworks de test.

Très bien, nous allons commencer une chaîne de commandes avec le get commande . Pour trouver un élément avec getnous devons d'abord trouver son sélecteur. Trouver un sélecteur unique est essentiel, car Cypress renverrait autrement tous les éléments correspondants ; alors gardez cela à l'esprit et évitez-le si cela n'est pas intentionnel.

Interagir avec des éléments

Cypress lui-même a une fonctionnalité pour vous aider à trouver les sélecteurs des éléments avec lesquels vous souhaitez travailler. Cette fonctionnalité s'appelle Selector Playgroundet elle vous aide à découvrir les sélecteurs uniques d'un composant ou à voir tous les éléments correspondants pour un sélecteur ou une chaîne de texte. Ainsi, cette fonctionnalité peut vous aider beaucoup dans cette tâche. Pour l'activer, cliquez simplement sur l'icône en forme de croix dans l'en-tête de l'interface utilisateur de votre test, puis survolez l'élément souhaité :

Comme on le voit dans la capture d'écran ci-dessus, une infobulle affichera le sélecteur au survol ou dans cette petite barre sous l'icône en forme de croix, qui apparaissait lorsque l'élément a été cliqué. Dans cette barre, vous pouvez également voir combien d'éléments correspondraient au sélecteur donné – garantissant son unicité dans notre cas.

Parfois, ces sélecteurs générés automatiquement peuvent ne pas être ceux que vous souhaitez utiliser (par exemple, s'ils sont longs ou difficiles lire ou ne pas remplir vos autres critères). Le sélecteur généré ci-dessous est difficile à comprendre et trop long, à mon humble avis :

Dans ce cas, je me rabattrais sur les DevTools du navigateur pour trouver mes sélecteurs uniques. Vous connaissez peut-être ces outils ; dans mon cas, je choisis souvent Chrome à cet effet. Cependant, d'autres navigateurs pris en charge peuvent fournir des fonctionnalités similaires. Le processus ressemble à celui du Selector Playground, sauf que nous utilisons les fonctionnalités de DevTools dans l'onglet "Element".

Pour vous assurer qu'un sélecteur est unique, je vous recommande de le rechercher dans la vue code de votre DevTools. Si vous ne trouvez qu'un seul résultat, vous pouvez être sûr qu'il est unique.

Saviez-vous qu'il existe de nombreux types de sélecteurs ? Selon la variété, les tests peuvent ressembler et même se comporter assez différemment. Certaines variétés sont mieux adaptées que d'autres aux tests de bout en bout. Si vous voulez savoir quels sélecteurs utiliser pour garder vos tests stables et propres, je peux vous diriger vers l'un de mes articles qui couvre ce problème. Les développeurs de Cypress eux-mêmes fournissent des conseils sur ce sujet dans leurs meilleures pratiques.

Our Test As A Sequence Of Commands

OK, revenons à notre test. Dans celui-ci, nous voulons afficher notre flux de travail :

« En tant qu'utilisateur, je vais rechercher l'article de l'auteur et accéder au site Web de l'auteur via la zone de référence dans l'un de ses articles. »

Nous allons reproduire les étapes qu'un utilisateur suivrait en utilisant des commandes. Je collerai ci-dessous le test terminé avec des commentaires, qui expliqueront les étapes :

// find-author.spec.js
it('Trouver l'auteur Ramona Schwering', () => {
  // Ouvrir le site
  cy.visit('https://www.smashingmagazine.com');

  // Entrez le nom de l'auteur dans le champ de recherche
  cy.get('#js-search-input').type('Ramona Schwering');

  // Accédez à l'article de l'auteur
  cy.get('h2 > a').first().click();

  // Ouvrir la page de l'auteur
  cy.get('.author-post__author-title').click();
});

Cet exemple traite du workflow que nous voulons tester. Cypress exécutera ce test. Alors, est-il temps de dire «                                                                                                                                                                                                                                                                                                 tement Avons-nous enfin fini d'écrire notre premier test ?

Eh bien, s'il vous plaît, regardez de plus près. Cypress l'exécutera, mais il ne fera que ce que le test lui dit, c'est-à-dire ce que vous avez écrit. Si vous l'exécutez dans le lanceur de test, vous pouvez voir s'il a réussi, mais pas au cas où vous l'auriez exécuté sans tête. Avec ce test, nous savons seulement si Cypress a pu exécuter nos commandes avec succès, pas si nous nous sommes retrouvés sur le site Web de l'auteur. Nous devons donc enseigner notre test pour déterminer cela. ou ne plus être visible. Les assertions dans Cypress sont basées sur les assertions Chai et Sinon-Chaice qui est perceptible dans la syntaxe.

N'oubliez pas que nous voulons vérifier si nous sommes sur le profil de l'auteur. page — la mienne dans cet exemple. Nous devons donc ajouter une assertion pour exactement cela :

// find-author.spec.js
it('Trouver l'auteur Ramona Schwering', () => {
  // Ouvrir le site
  cy.visit('https://www.smashingmagazine.com');

  // Entrez le nom de l'auteur dans le champ de recherche
  cy.get('#js-search-input').type('Ramona Schwering');

  // Accédez à l'article de l'auteur
  cy.get('h2 > a').first().click();

  // Ouvrir la page de l'auteur
  cy.get('.author-post__author-title').click();

  // Vérifier si nous sommes sur le site de l'auteur
  cy.contains('.author__title', 'Ramona Schwering').should('be.visible');
});

Très bien, nous avons maintenant écrit un test qui a de la valeur. Alors, oui, félicitations pour avoir écrit votre premier test… même s'il n'est pas encore parfait. Je ne fusionnerais pas encore celui-ci s'il était proposé dans une pull request. Il reste quelques choses à faire pour le faire briller.

Prenez votre temps

Cypress a une option de nouvelle tentative intégrée dans presque chaque commande, vous n'avez donc pas à attendre pour voir si, par exemple, un élément existe déjà. Cependant, cela ne regarde que si un élément existe dans le DOM, pas plus que cela. Cypress ne peut pas prédire tout ce que fait votre application, il peut donc y avoir une certaine floconnage si vous vous fiez uniquement à cela.

Que ferait un utilisateur s'il voulait voir un site Web en cours de chargement ? Ils attendraient très probablement que certaines parties du site Web deviennent visibles (donc chargées) et interagiraient ensuite avec eux. Dans notre test, nous voulons imiter précisément cela : nous voulons attendre les changements dans l'interface utilisateur avant de commencer à interagir . Dans la plupart des cas, nous limiterions ce comportement aux éléments dont nous avons besoin, utilisant ainsi des assertions sur ces éléments.

Comme vous pouvez le voir, nous devons faire attendre notre test à plusieurs reprises. Cependant, attendre trop de fois n'est pas bon non plus. En règle générale, je suggère d'utiliser une assertion pour vérifier si l'élément avec lequel interagir est complètement chargé, comme première étape pour déterminer si le site Web testé a été chargé.

Jetons un coup d'œil à un tel partie de notre test à titre d'exemple. J'ai ajouté une assertion à assurez-vous que notre page est entièrement chargée :

// find-author-assertions.spec.js
// Ouvrir le site
cy.visit('https://www.smashingmagazine.com');

// Assurez-vous que le site est complètement chargé
cy.get('.headline-content').should('be.visible');

// Entrez le nom de l'auteur dans le champ de recherche
cy.get('#js-search-input').type('Ramona Schwering');

Continuez à ajouter des assertions de cette manière à tous les cas où notre site Web aura des temps de chargement ou plusieurs éléments qui doivent être rendus un nouveau. Pour le fichier de test complet, veuillez consulter le test correspondant dans le référentiel GitHub.

Pour éviter de tomber dans le piège des tests floconneux, je voudrais vous donner un dernier indice : Jamais utilisez des temps d'attente fixestels que cy.wait(500) ou similaire.

Les réponses API sont vos amis

Il y a une possibilité d'attente intéressante en particulier que j'aime utiliser de dans mes tests. Dans Cypress, il est possible de travailler avec des fonctionnalités réseau — un autre moyen utile d'attendre dans votre application consiste à utiliser ces fonctionnalités pour travailler avec des requêtes réseau. De cette façon, vous pouvez faire en sorte que le test attende une réponse API réussie.

Si nous nous souvenons de notre flux de travail à titre d'exemple, une étape pourrait faire grand usage d'une possibilité d'attente API. Je pense à la recherche. Une user story correspondante pourrait être la suivante :

"En tant que développeur, je veux m'assurer que nos résultats de recherche sont entièrement chargés afin qu'aucun article de résultats plus anciens ne trompe notre test."

Appliquons cela à notre essai. Tout d'abord, nous devons définir l'itinéraire que nous voulons attendre plus tard. Nous pouvons utiliser la commande intercept pour cela. Je rechercherais la demande, en apportant les données dont j'ai besoin – les résultats de la recherche dans ce cas.

Pour garder cet exemple simple, j'utiliserai un caractère générique pour l'URL. Après cela, j'utiliserai un alias pour que Cypress puisse travailler avec cette route plus tard.

// find-author-hooks.spec.js
// Définir la route avec laquelle travailler
it('Trouver l'auteur Ramona Schwering', () => {

  // Route à attendre plus tard
  cy.intercepter({
    URL : '*/indexes/smashingmagazine/*',
    méthode : 'POSTER'
  }).as('recherche'); // Avec cet alias Cypress retrouvera la requête

  //...

Dans Cypress, toutes les routes définies sont affichées au début du test. Donc, j'aimerais également mettre ces commandes intercept au début de mon test.

Maintenant, nous pouvons utiliser cet alias de route dans les assertions. Le moyen le plus simple de le faire serait d'utiliser la commande wait de Cypress, directement avec l'alias mentionné précédemment. Cependant, l'utilisation de cette commande seule conduirait à attendre la réponse quel que soit son résultat . Même les codes d'erreur tels que 400 ou 500 seraient considérés comme réussis, alors que votre application s'effondrerait très probablement. Je recommanderais donc d'ajouter une autre assertion comme celle-ci :

// find-author-hooks.spec.js
// Plus tard : Affirmation du code d'état de la requête de recherche
cy.wait('@recherche')
   .its('response.statusCode').should('equal', 200);

De cette façon, nous pouvons attendre les données du logiciel, les modifications, etc. avec précision, sans perdre de temps ni rencontrer de problèmes si l'application est fortement sollicitée. Encore une fois, vous pouvez trouver le fichier d'exemple complet dans mon référentiel GitHub.

Configuration de Cypress

J'ai omis un petit détail. Si vous regardez de plus près l'exemple de test complet, il diffère légèrement de ceux que nous avons utilisés ici dans ce guide.

// Cypress
describe('Trouver l'auteur à smashing', () => {
  avantChaque(() => {
    // Ouvrir le site
    cy.visit('https://www.smashingmagazine.com');
  });

//...

Je n'utilise qu'une barre oblique pour ouvrir le site Web de Smashing Magazine. Comment ça marche? Eh bien, en utilisant cette commande comme cela, vous accédez à la baseUrl de nos tests. baseUrl est une valeur de configuration qui peut être utilisée comme préfixe pour l'URL de la commande cy.visit() ou cy.request(). Parmi d'autres valeursnous pouvons définir cette valeur dans le fichier cypress.json. Pour notre test, nous allons définir la baseUrl comme ceci :

// cypress.json
{
  "baseUrl": "http://www.smashingmagazine.com"
}

Mention honorable : Hooks

Il reste un sujet que je souhaite mentionner, même si notre exemple de test n'est pas adapté à son utilisation. Comme c'est souvent le cas dans d'autres frameworks de test, nous pouvons définir ce qui se passe avant et après nos tests via ce que l'on appelle des hooks de cycle de vie. Plus précisément, ceux-ci existent pour exécuter du code avant ou après un ou tous les tests :

// Cypress
describe('Hooks', function() {
  avant (() => {
    // S'exécute une fois avant tous les tests
  });

  après (() => {
    // S'exécute une fois après tous les tests
  });

  avantChaque(() => {
    // Exécute avant chaque test
  });

  aprèsChaque(() => {
    // Exécute après chaque test
  });
});

Nous voulons remplir notre fichier de test avec plusieurs tests, nous devons donc rechercher les étapes courantes que nous souhaitons exécuter avant ou après celles-ci. Notre première ligne est un bon exemple, étant la commande visit. En supposant que nous souhaitions ouvrir ce site Web avant chacun de ces tests, un hook beforeEach dans notre exemple ressemblerait à ceci :

// Cypress
describe('Trouver l'auteur à smashing', () => {
  avantChaque(() => {
    // Ouvrir le site
    cy.visit('https://www.smashingmagazine.com');
  });

  //...
Crochet 

Je l'utilise fréquemment dans mon travail quotidien pour m'assurer, par exemple, que mon application est réinitialisée à son état par défaut avant le testisolant ainsi le test des autres tests. (Ne vous fiez jamais aux tests précédents !) Exécutez vos tests indépendamment les uns des autres pour garder le contrôle sur l'état de l'application.

Chaque test doit pouvoir s'exécuter seul, indépendamment des autres tests. Ceci est essentiel pour garantir des résultats de test valides. Pour plus de détails à ce sujet, consultez la section «  Données que nous avions l'habitude de partager » dans l'un de mes articles récents. Pour l'instant, référez-vous à l'exemple complet sur GitHub si vous souhaitez voir l'intégralité du test.

Conclusion

À mon avis, les tests de bout en bout sont un composant essentiel de CI, en gardant la qualité des applications à un niveau élevé tout en allégeant le travail des testeurs. Cypress est mon outil de choix pour déboguer des tests de bout en bout rapidement, de manière stable et efficace, et pour les exécuter parallèlement à toute demande d'extraction dans le cadre de CI. La courbe d'apprentissage est douce si vous êtes déjà familiarisé avec JavaScript.

J'espère avoir pu vous guider un peu et vous avoir donné un point de départ pour écrire des tests Cypress et quelques conseils pratiques pour commencer. Of course, all code examples are available in the GitHub repositoryso feel free to take a look.

Of course, this is only a starting point; there are many more things to learn and discuss regarding Cypress tests — I’ll leave you with some suggestions on what to learn next. With this in mind, happy testing!

Resources

(vf, yk, al, il)