[Case study] NightWatchJS et les tests E2E

Dans l’univers du test E2E, un des premiers noms qui nous vient à l’esprit c’est Selenium et ça tombe bien parce qu'aujourd’hui nous allons découvrir une bibliothèque Javascript qui peut s’appuyer sur Selenium : NightWatchJS. À la base, nous connaissions CasperJS, mais nous nous sommes confrontés à un cas particulier : les iframes.

La promesse de NightWatch est simple : Write End-To-End tests in Node.js quickly and effortlessly that run against a Selenium/WebDriver server. Nous allons voir dans cet article que son utilisation répond bien à ces promesses.

Tout d'abord, si vous n’avez pas encore NodeJS rendez-vous ici pour l’installer et n’oubliez pas d’installer le gestionnaire de paquet npm.

Ensuite il nous faut de quoi ouvrir les pages à tester :)

À la racine du projet, créez un fichier nightwatch.json : 

Ensuite, puisque nous y faisons référence, créons le fichier globals.js à la racine du projet :

Dans ce fichier, nous définissons des actions à lancer en début et fin d'exécution des tests ainsi qu’après chaque test. Il est possible aussi de définir des variables qui auront des implications dans les différentes commandes accessibles, ou simplement qui seront accessibles depuis les tests. Jetez un coup d'oeil à la doc, il existe d’autres options disponibles :)

Une fois la configuration terminée, nous allons pouvoir écrire nos tests. Dans le répertoire tests, commencez par créer un répertoire « searchEngine » . C’est un nom arbitraire puisque de toute manière, dans la configuration, nous avons défini que tous les tests seraient dans le répertoire tests. NightWatch considérera ainsi que tous les modules seront exportés comme des tests, peu importe où ils se trouvent dans ce répertoire. Ce répertoire « searchEngine » contiendra le fichier testResearch.js

Et voilà ! Le premier test est écrit et nous pouvons l’exécuter avec la commande suivante :

Là, quelques explications sont les bienvenues. Lors du npm init, nous précisons test command: ./node_modules/nightwatch/bin/nightwatch. Cela signifie que « test » est un alias. À vous de constater le résultat.

Ensuite, on souhaite exécuter le même test sur qwant. La première solution est de dupliquer le fichier searchEngine.js, le renommer et de modifier l’url. Ok, ça nous a pris 2 secondes, mais on a dupliqué le code, et si demain on doit tester 500 sites web, bonjour les dégats… Alors on passe tout de suite au truc cool, le PageObject. C’est une représentation d’une page par son DOM. L’idée, c’est que l’on va créer un pageObject par url sur laquelle on va vouloir jouer nos tests. Ainsi, si on joue plusieurs tests sur la même page, il n’y aura qu’un seul fichier à éditer et qu’une seule ligne par élément qui puisse changer en cas d’évolution dans la page.

Concrètement une pageObject c’est ça :

On va étoffer ça, rassurez-vous… Si l’url doit être dynamique, ce n’est pas un souci.

Nous vous renvoyons à la doc pour la définition de launchUrl, il faut regarder côté globals. Les éléments correspondent à des sélecteurs du DOM. 

searchBar est un nom arbitraire, qui vous servira pour cibler l’élément dans votre suite de test.

Vous aurez remarqué browser.page.google(). Souvenez vous, nous avons défini le répertoire « pages »  comme répertoire des pageObject dans la configuration. NightWatch va donc parcourir ce répertoire et instancier des pageObject avec chaque module exporté. Il stockera l’objet obtenu dans l’attribut page du browser. Le nom de l’objet correspond au nom du fichier js. Il faudra donc appeler le fichier google.js pour aller chercher browser.page.google(). Attention à bien mettre les parenthèses car l’objet est défini dans une closure.

Passons maintenant aux éléments. Les éléments, c'est bien mais si on veut éviter une liste sans fin, on peut grouper le tout avec des Sections.

L’avantage c’est que c’est récursif. Admettons la suite suivante :

Nous appliquons des règles CSS pour trouver chacun des éléments reprenant systématiquement la règle du parent. Et là, nous voyons déjà venir la question qui vous taraude : dans section, on retrouve des éléments mais peut-on mettre une section dans une section ? Oui, on peut.

Selon la version que vous utilisez, vous pouvez aussi dire à NightWatch de Skip (ne pas jouer) un test. Deux méthodes existent. La première, qui marche toute version confondue, est de transformer la fonction ‘Test’ en chaîne de caractères en ajoutant tout simplement ‘’+ devant le mot clé function.

Exemple :

Et l'autre qui consiste a ajouter à l’objet une propriété @disable à true. Exemple :

Il faudra rajouter l’option —tag à votre commande suivi du tag en question et c’est tout ! Enfin, pour l’instant parce que nous avons d’autres problématiques à mettre en place et c’est là que les choses sérieuses vont commencer. Si vous avez un bout de code qui doit être réutilisé pour chaque test pour une page, alors ajoutez une commande dans la page :

Si vous avez un bout de code qui doit être réutilisé absolument partout (dans tous les tests), alors ajoutez une commande dans le browser : la custom command.

Créez un fichier IfElementVisible.js dans le répertoire commands (comme d’hab on l’a défini au tout début dans le custom_commands_path). De la même manière que les pages, le nom du fichier, est le nom de la commande.

Et pour l'utiliser :

Ici, la touche XP ++ est présente parce que si vous utilisez les dernières versions stables 0.9.12 à l'heure actuelle, les customs commands ne prennent que des chaînes de caractère. Dans notre exemple il n'y a pas de problème, mais si vous voulez utiliser un élément défini dans une page (autrement dit page.section.maSection.maCommande(‘@element’);) vous devrez utiliser master sans quoi vous recevrez une chaine au lieu de l’élément. Pour plus de sécurité, bloquez votre package sur un commit précis plutôt que master.

Autre cas, si vous devez intéragir avec du JS présent dans la page (par exemple jQuery), c’est possible ! Il existe déjà quelques commandes ou assertions écrite par Massimo Galbusera sur https://github.com/maxgalbu/nightwatch-custom-commands-assertions et sinon, la base de chaque commande jQuery est toujours la même donc il y a même moyen de rendre ça plus extensible. 

En parlant d’extension, admettons que vous ayez besoin d’avoir une base commune a toutes vos pages :

Et on l’utilise comme ça :

Voilà, on a fait un bon tour de tout ce qui était possible de faire avec NightWatch ! Nous vous épargnons l’entièreté des vérifications possible et imaginables via assert, expect, et les commandes puisque la doc est bien pour ça. Dernier conseil : browser.pause dans un browser.perform sera votre ami pour exécuter des opérations asynchrones.

NightWatch est très bon dans son domaine. Il n’enlève pas les contraintes des tests e2e qui sont les délais liés au réseau ou au navigateur (plus rare) ou les lenteurs du JS qui font que le script va trop vite pour la librairie. Il est fiable si la page testée permet d’écrire des tests avec les élément cités plus haut. Il arrive parfois que vous n’ayez pas toujours accès au DOM et que vous devrez contourner l’absence d’ID ou de classes sur les éléments de DOM et c’est possible. Vous pouvez alors préciser que le sélecteur que vous utilisez est un xpath et vous pourrez construire des règles plus compliqués.

Dernier point : si NightWatch trouve plusieurs éléments pour un sélecteur, au choix, soit il plante soit il prend le premier, à vous de configurer le comportement. Le créateur de cet outil est plutôt réactif sur github et il y a pas mal de monde qui l’utilise alors ce ne sera jamais vraiment une difficulté de trouver la réponse à un de vos problèmes sur google ou dans les issues.

Et vous, quelle est votre expérience de NightWatch ? Nous serions ravis de lire vos retours à ce sujet :)