Mise en place de Cypress.js dans Gitlab CI – partie 1

Cette article est divisé en deux parties. La première explique comment mettre en place des tests end-to-end dans une application très simple, en découvrant quelques fonctionnalités très pratiques de Cypress.js. La deuxième (en cours d’écriture) expliquera comment intégrer ces tests dans Gitlab CI, de la mise en place des jobs et pipelines aux différents workflows de tests que l’on utilise.

Passer de Nightwatch.js à Cypress.js

Cypress.js a été pour nous une révolution. Nous avons utilisé Nightwatch.js pendant un long moment. Nous en étions assez content, mais quand nous avons testé Cypress.js, il était assez clair pour nous qu’il était pertinent de changer, principalement pour deux raisons :

• Stabilité : nous avons eu beaucoup de mauvaises surprises (principalement des tests qui échouent une fois mais réussissent le reste du temps ou des problèmes d’interaction avec certains elements, click, type…) en utilisant différents frameworks de tests end-to-end. Cypress.js n’est pas parfait mais il est beaucoup plus stable, en grande partie parce qu’il n’utilise pas Selenium.
• Experience de développement : enregistrement de videos, progression des tests, logger, debugger, attente automatique, time travel, reload automatique, etc. Cypress.js possède une quantité d’outils considérable pour les développeurs, ce qui fait de son utilisation un véritable plaisir.

J’aime travailler sur des projets simples pour illustrer mes propos. On va donc utiliser ce (faux) site web pour explorer ce que peut faire Cypress.

Il est temps d’aider Jordan, un développeur curieux qui a décidé d’apprendre à tester son application. Jordan a choisi (sans aucune influence) de tester son application avec Cypress.js.

Premiers pas avec Cypress.js

Jordan a son site en production, prêt à être testé. La première chose qu’il doit faire est d’installer Cypress.

npm install cypress --save-dev

Il ajoute ensuite un nouveau script dans son package.json pour pouvoir lancer ses tests.

"scripts": {
  "cypress:open": "cypress open"   
}

Il peut ensuite lancer la commande :

npm run cypress:open

Et voilà ! Jordan est prêt. L’installation n’est pas très complexe.

Note: Cypress.js génère beaucoup de tests. C’est utile pour voir à quoi ça ressemble, mais comme ce n’est pas vraiment le sujet. Jordan va supprimer tous les exemples qui ont été créés dans le dossier integration .

Écrire son premier test

Jordan se demande :

Qu’est-ce qu’il faut que je teste ?

Certaines personnes ont beaucoup d’inspiration, d’autres beaucoup moins. Regardons déjà ce que fait ce site web pour savoir ce qu’il faut tester.

Jordan sait qu’une grande partie de son trafic arrive directement sur sa page d’accueil (car il utilise des outils analytics, c’est pas n’importe qui). En arrivant sur la page d’accueil, les utilisateurs choisissent ensuite de créer un compte ou de se connecter. Et c’est tout. Pas le site le plus intéressant, mais bon.

Je pense que si tous mes utilisateurs arrivent sur la page d’accueil, je devrais commencer par tester que ma page d’accueil est fonctionnelle.

Bien joué Jordan.

Avec un peu d’aide (vraiment pas beaucoup), Jordan crée un nouveau fichier qu’il appelle homepage.spec.js et le remplit avec le contenu suivant :

• cy.visit() est utilisé pour aller sur une URL passée en paramètre.
• cy.get() est utilisé pour récupérer un élément dans le DOM et .should('exist') vérifie que cet élément existe bien dans le DOM.

Note: cy.get() utilise les query selectors pour sélectionner les éléments ans le DOM. data-cy est un data-attribute (data-*) que l’on peut mettre sur n’importe quelle balise HTML (ou presque). Il est préférable d’utiliser des data-attributes plutôt que des ids ou des classes pour ne pas entrer en conflit avec les modifications liées à l’affichage de la page (changement de style par exemple). Points bonus pour les data-attributes qui servent aussi à expliquer pourquoi ils sont là, tous les data-cy sont là pour permettre à Cypress de sélectionner les éléments (cf.Cypress.js Best practices).

Jordan peut maintenant lancer son test directement depuis l’interface graphique de Cypress.

Jusqu’ici tout est bon.

Tests avec des interactions utilisateur

Ok, je peux maintenant savoir si ma page d’accueil s’affiche correctement. Il est temps de tester ma page de connexion.

Lorsqu’on souhaite tester des fonctionnalités qui sont dépendantes de données (comme la connexion par exemple), il faut être sûr que, par exemple pour la connexion, le compte qu’on utilise pour se connecter existe (ou n’existe pas si c’est ce qu’on souhaite tester). Le compte que Jordan va utiliser pour son test sera toujours le même et a été créé dans ce but : servir de compte de test.
Un autre exemple pourrait être un article. Si nous avions un blog, le but du test de l’article ne serait pas d’en prendre un au hasard depuis la page d’accueil. Nous voudrions garder toujours le même pour garder le test consistant. Revenons au site de Jordan.

Note: Ce site accepte toutes les adresses emails et tous les mots de passe (oui c’est un faux site).

Jordan doit trouver quel workflow de login il veut tester en premier.

Mes utilisateurs arrivent principalement sur ma page principale avant de se connecter, il faudrait donc que je teste le workflow suivant :

– l’utilisateur arrive sur la page d’accueil
– l’utilisateur navigue sur la page de connexion via le menu
– l’utilisateur entre son adresse e-mail et son mot de passe
– l’utilisateur est connecté

Et voici à quoi ressemble le test qu’il écrit :

Les commandes Cypress sont assez simples à comprendre si on parle un minimum anglais. Regardons ce que font ces nouvelles commandes :

cy.url().should('eq', 'XXX')

Celle-ci permet de récupérer l’URL courante puis d’utiliser l’assertion should pour vérifier que l’URL est bien égale ('eq') au second paramètre.

type et click peuvent être utilisés avec get pour taper dans un champ ou cliquer sur un élément.

Le test fonctionne sans soucis.

Je voudrais maintenant poser une question simple. En regardant le code au-dessus qui (je pense) n’est pas très difficile à produire, à quel point ces tests pourraient être utilisés pour votre site web sur vos fonctionnalités principales par rapport au temps nécessaire pour les mettre en place ?

Je pense personnellement qu’ils sont un excellent investissement. Je vais continuer cette article sur les fonctionnalités de Cypress, car je souhaite garder cette article structuré. Si j’étais à la place de Jordan, j’arrêterai de développer des suites de tests et j’essayerai d’intégrer les tests que j’ai déjà écrits dans ma CI.

Le plus important n’est pas de couvrir toutes les fonctionnalités de votre site web mais plutôt de couvrir les workflows les plus importants pour être sûr qu’ils ne cassent pas. On peut toujours ajouter des suites de tests plus tard. Retournons sur le site de Jordan.

Commandes personnalisées de Cypress

Je n’aime pas vraiment mettre mes URLs en dur dans mon code. Et si je veux avoir une configuration différente en fonction des mes environnements ? Et si mes URLs changent dans mon routeur ?

Ne t’inquiète pas Jordan, on va faire ça mieux. Imaginons qu’on utilise un routeur. Il serait bien plus simple de pouvoir écrire des instructions de navigation de cette façon plutôt que de taper les URLs :

cy.goTo('home')
cy.goTo('login')
cy.goTo('signup')

On peut créer une commande personnalisée goTo pour répondre à ce besoin. Commençons par créer un “faux” router. L’implémentation dépendra de votre router mais l’idée reste la même. Voici donc notre router services/router.js :

Maintenant qu’on a un router, on peut l’utiliser dans notre fichier support/commands.js .

Et on peut maintenant utiliser cette commande dans notre suite de tests (pas besoin d’utiliser require pour récupérer la commande):

npm install axios