Automatisation des tests : présentation de l’outil CodeceptJS

Automatiser les tests fonctionnels et API est une problématique récurrente sur les projets agiles. Les solutions sont nombreuses et les langages de scripting potentiels assez vastes : java, c#, python et plus récemment java script (JS). Dans cet article, rédigé par un de nos ingénieurs automatisation des tests, nous allons vous présenter un outil de la famille des helper dénommé CodeceptJS qui devrait vous aider si vous avez un projet à lancer sur ces techno JS. 

CodeceptJS est un Framework de test de bout en bout (End 2 End) moderne avec une syntaxe spéciale de style BDD. Les tests sont écrits comme un scénario linéaire de l’action de l’utilisateur sur un site. Nous parlerons dans cet article de son architecture, BDD, locators, PageObject, configuration et exécution  parallèle.

1. Pourquoi CodeceptJS ?

CodeceptJS est un successeur de Codeception, un framework de test full-stack. Avec CodeceptJS, vos tests fonctionnels et d’acceptation basés sur des scénarios seront aussi simples et propres que possible. Vous n’avez pas à vous soucier de la nature asynchrone de NodeJS ou des différentes API de Selenium, Puppeteer, Protractor, TestCafe etc., car CodeceptJS les unifie et les fait fonctionner comme s’ils étaient synchrones.

Les tests CodeceptJS sont :

• Synchrones : Vous n’avez pas besoin de vous soucier des rappels ou des promesses, les scénarios de test sont linéaires, votre test devrait l’être aussi.
• Écrit du point de vue de l’utilisateur. Chaque action est une méthode de « I ». Cela rend le test facile à lire, à écrire et à maintenir, même pour les non-techniciens.
• API back-end agnostique. Nous ne savons pas quelle implémentation WebDriver exécute ce test. Nous pouvons facilement passer de WebDriverIO à Protractor ou PhantomJS.

CodeceptJS utilise des modules d’assistance « Helper » pour fournir des actions à l’objet I. Actuellement CodeceptJS a ces assistants :

• WebDriver – utilise webdriverio pour exécuter des tests via le protocole WebDriver.
• Protractor – assistant autorisé par Protractor à exécuter des tests via le protocole WebDriver. Consultez notre article pour Commencer avec Protractor-Angular.
• TestCafe – automatisation de test multi-navigateur rapide et bon marché.
• Puppeteer- une bibliothèque Node qui fournit une API de haut niveau pour contrôler Chrome ou Chromium via le protocole DevTools.
• Playwright -une bibliothèque Node pour automatiser Chromium, Firefox et WebKit avec une seule API.
• Nightmare – utilise Electron et NightmareJS pour exécuter des tests.
• Appium – pour les tests mobiles avec Appium.

2. Architecture

CodeceptJS contourne les commandes d’exécution pour les assistants. Selon l’aide activée, vos tests seront exécutés différemment. Si vous avez besoin d’une prise en charge multi-navigateurs, vous devez choisir WebDriver ou TestCafé basé sur Selenium. Si vous êtes intéressé par la vitesse, vous devez utiliser Puppeteer basé sur Chrome.

Tous les assistants partagent la même API, il est donc facile de migrer les tests d’un backend à un autre. Cependant, en raison de la différence des backends et de leurs limites, ils ne sont pas garantis pour être compatibles les uns avec les autres. Par exemple, vous ne pouvez pas définir d’en-têtes de demande dans WebDriver ou Protractor, mais vous pouvez le faire dans Puppteer ou Nightmare.

3. Behavior-driven development (BDD)

Qu’est-ce que Le développement axé sur le comportement (BDD) ?

BDD a sa propre évolution depuis sa naissance, en commençant par remplacer “test” par “devrait” dans les tests unitaires, et en s’orientant vers des outils puissants comme Cucumber et Behat, qui ont fait que les user stories (texte lisible par l’homme) soient exécutées en tant que test d’acceptation . Pour en savoir plus sur comment automatiser vos tests logiciels en utilisant c#, bdd et spekflow consultez cet article.

L’objectif de  BDD est de :

• Décrire les caractéristiques d’un scénario avec un texte formel
• Utiliser des exemples pour concrétiser des choses abstraites
• Implémenter chaque étape d’un scénario de test
• Ecrire du code réel implémentant la fonctionnalité.

CodeceptJS peut exécuter ce scénario étape par étape comme un test automatisé. Chaque étape de ce scénario nécessite un code qui le définit.

Gherkin :

Apprenons un peu plus sur le format Gherkin et ensuite nous verrons comment l’exécuter avec CodeceptJS. Nous pouvons activer Gherkin pour le projet en cours en exécutant la commande gherkin : init sur un projet déjà initialisé :

Il ajoutera une section gherkin à la configuration actuelle. Il préparera également des répertoires pour les fonctionnalités et la définition des étapes. Et il créera le premier fichier de fonctionnalités pour vous.

Features (fonctionnalités)

Chaque fois que vous commencez à écrire une histoire, vous décrivez une fonctionnalité spécifique d’une application, avec un ensemble de scénarios et d’exemples décrivant cette fonctionnalité. Ouvrons un fichier de fonctionnalité créé par la commande gherkin : init, qui est feature / basic.feature.

Ce texte doit être réécrit pour suivre vos règles commerciales. Ne pensez pas à une interface Web pendant un certain temps. Pensez à la façon dont les utilisateurs interagissent avec votre système et aux objectifs qu’ils souhaitent atteindre. Ensuite, écrivez des scénarios d’interaction.

Scenarios (Scénarios)

Les scénarios sont des exemples en direct d’utilisation des fonctionnalités. À l’intérieur d’un fichier d’entités, il doit être écrit dans un bloc d’entités. Chaque scénario doit contenir son titre :

Les scénarios sont rédigés étape par étape en utilisant l’approche Given-When-Then. Au début, le scénario doit décrire son contexte avec le mot-clé Given :

Ici, nous utilisons également le mot Et pour étendre le Donné et non pour le répéter dans chaque ligne.

C’est ainsi que nous avons décrit les conditions initiales. Ensuite, nous effectuons une action. Nous utilisons le mot clé When pour cela :

Et à la fin, nous vérifions nos attentes en utilisant le mot-clé Then. L’action a changé l’état donné initial et a produit des résultats. Vérifions que ces résultats correspondent à ce que nous attendons réellement.

Ces scénarios sont agréables en tant que documentation en direct mais ils ne testent encore rien. Ce dont nous avons besoin ensuite, c’est de définir comment exécuter ces étapes. Les étapes peuvent être définies en exécutant la commande gherkin : snippets :

Cela produira des modèles de code pour toutes les étapes non définies dans les fichiers .feature. Par défaut, il analysera tous les fichiers .feature spécifiés dans la section gherkin.features de la configuration et produira des modèles de code pour toutes les étapes non définies. Si l’option –feature est spécifiée, elle analysera le ou les fichiers .feature spécifiés. Les définitions de stub par défaut seront placées dans le premier fichier spécifié dans la section gherkin.steps de la configuration. Cependant, vous pouvez également utiliser –path pour spécifier un fichier spécifique dans lequel placer toutes les étapes non définies. Ce fichier doit exister et être dans le tableau gherkin.steps de la configuration. Notre prochaine étape sera de définir ces étapes et de transformer le fichier de caractéristiques en un test valide.

Step Definitions :

Les définitions d’étapes sont placées dans un fichier JavaScript avec les fonctions Given / When / Then qui mappent les chaînes du fichier d’entités aux fonctions :

Les étapes peuvent être des chaînes ou des expressions régulières. Les paramètres de la chaîne sont passés comme arguments de fonction. Pour définir les paramètres dans une chaîne, nous utilisons des expressions de Cucumber.

Pour répertorier toutes les étapes définies, exécutez la commande gherkin: steps:

Pour exécuter des tests et voir la sortie étape par étape, utilisez l’option –types:

Pour voir non seulement les étapes métier mais les étapes réellement exécutées, utilisez l’indicateur –debug:

Tags

Les scénarios et fonctionnalités de Gherkin peuvent contenir des balises marquées d’un @. Les balises sont ajoutées aux titres des fonctionnalités afin que vous puissiez facilement les filtrer lors de l’exécution des tests :

La balise doit être placée avant le scénario : ou avant le mot clé Feature:. Dans le dernier cas, tous les scénarios de cette fonctionnalité seront ajoutés au groupe correspondant.

Configuration

Gherkin :

• Features :chemin d’accès aux fichiers de fonctionnalités
• steps : tableau de fichiers avec définitions d’étapes

4. Locators

CodeceptJS propose des stratégies flexibles pour localiser les éléments :

• Localisateurs CSS et XPath
• Localisateurs sémantiques : par texte de lien, par texte de bouton, par nom de champ, etc.
• Constructeur de localisateur
• Localisateurs d’ID : par ID CSS ou par ID d’accessibilité
• Stratégies de localisation personnalisées : par des attributs de données ou tout ce que vous préférez.
• Shadow DOM : pour accéder aux éléments shadow dom
• React: pour accéder aux éléments React par noms de composants et accessoires

La plupart des méthodes de CodeceptJS utilisent des localisateurs qui peuvent être soit une chaîne soit un objet.

Si le localisateur est un objet, il doit avoir un seul élément, la clé indiquant le type de localisateur (id, name, css, xpath, link, react ou class) et la valeur étant le localisateur lui-même. C’est ce qu’on appelle un localisateur “strict”.

Exemples :

Écrire de bons localisateurs peut être délicat. L’équipe Mozilla a écrit un excellent guide intitulé ” Écrire des localisateurs fiables pour les tests Selenium et WebDriver “.

Si vous préférez, vous pouvez également passer une chaîne pour le localisateur. C’est ce qu’on appelle un localisateur “flou”. Dans ce cas, CodeceptJS utilise une variété d’heuristiques (selon la méthode exacte appelée) pour déterminer à quel élément vous faites référence. Si vous recherchez un élément cliquable ou un élément d’entrée, CodeceptJS utilisera des localisateurs sémantiques.

Par exemple, voici l’heuristique utilisée pour la méthode fillField:

• Le localisateur ressemble-t-il à un sélecteur d’ID (par exemple “#foo”)? Si c’est le cas, essayez de trouver un élément d’entrée correspondant à cet ID.
• Si rien n’est trouvé, vérifiez si le localisateur ressemble à un sélecteur CSS. Si oui, lancez-le.
• Si rien n’est trouvé, vérifiez si le localisateur ressemble à une expression XPath. Si oui, lancez-le.
• Si rien n’est trouvé, vérifiez s’il y a un élément d’entrée avec un nom correspondant.
• Si rien n’est trouvé, vérifiez s’il existe une étiquette avec le texte spécifié pour l’élément d’entrée.
• Si rien n’est trouvé, lève une exception ElementNotFound.

5. Page Objects

L’interface utilisateur de votre application Web possède des zones d’interaction qui peuvent être partagées entre différents tests. Pour éviter la duplication de code, vous pouvez placer les localisateurs et méthodes communs en un seul endroit.

Dependency Injection (Injection de dépendance)

Tous les objets décrits ici sont injectés avec l’injection de dépendance. De la même manière, cela se produit dans le cadre AngularJS. Si vous voulez qu’un objet soit injecté dans le scénario par son nom, ajoutez-le à la configuration :

Maintenant, ces objets peuvent être récupérés par le nom spécifié dans la configuration.

Les objets requis peuvent être obtenus via les paramètres des tests ou via l’appel global inject ().

Actor

Lors de l’initialisation, vous avez été invité à créer un fichier d’étapes personnalisé. Si vous avez accepté cette option, vous pouvez utiliser le fichier custom_steps.js pour étendre I. Voir comment la méthode de connexion peut être ajoutée à I.

PageObject

Dans le cas où une application a différentes pages (login, admin, etc.), vous devez utiliser le Page Object. CodeceptJS peut générer un modèle pour cela avec la commande :

Cela créera un exemple de modèle pour un Page object et l’inclura dans la configuration codecept.json.

Comme vous le voyez, I’object est disponible là-bas afin que vous puissiez l’utiliser comme vous le faites dans les tests. Page object général d’une page de connexion peut ressembler à ceci :

Vous pouvez inclure cet Page object dans test par son nom (défini dans codecept.json). Si vous avez créé un objet loginPage, il doit être ajouté à la liste des arguments de test à inclure dans le test :

Vous pouvez également utiliser async / wait dans PageObject :

Et utilisez-les dans vos tests :

Les objets de page peuvent être des fonctions, des tableaux ou des classes. Lorsque des objets de page déclarés en tant que classes, vous pouvez facilement les étendre dans d’autres objets de page. Voici un exemple de déclaration d’un Page object en tant que classe :

6. Exécution parallèle

CodeceptJS dispose de deux moteurs pour exécuter des tests en parallèle :

• run-workers – qui engendre NodeJS Worker dans un thread. Les tests sont divisés par scénarios, les scénarios sont mélangés entre les groupes, chaque travailleur exécute des tests à partir de son propre groupe
• run-multiple – qui génère un sous-processus avec CodeceptJS. Les tests sont divisés par fichiers et configurés dans codecept.conf.js.

Les travailleurs sont plus rapides et plus simples à démarrer, tandis que run-multiple nécessite une configuration supplémentaire et peut être utilisé pour exécuter des tests dans différents navigateurs à la fois.

Exécution parallèle par les travailleurs

Il est facile d’exécuter des tests en parallèle si vous disposez de nombreux tests et de cœurs de processeur gratuits. Exécutez simplement vos tests à l’aide de la commande run-workers spécifiant le nombre de travailleurs à générer :

Cette commande est similaire à l’exécution, cependant, la sortie des étapes ne peut pas être affichée en mode de travail, car il est impossible de synchroniser la sortie des étapes de différents processus.

Chaque travailleur fait tourner une instance de CodeceptJS, exécute un groupe de tests et renvoie un rapport au processus principal.

Par défaut, les tests sont assignés un par un aux travailleurs disponibles, ce qui peut conduire à plusieurs exécutions de BeforeSuite (). Utilisez l’option –suites pour affecter les suites une par une aux travailleurs.

Exécution de plusieurs navigateurs

Ceci est utile si vous souhaitez exécuter les mêmes tests mais sur des navigateurs différents et avec des configurations différentes ou des tests différents sur les mêmes navigateurs en parallèle.

Créez plusieurs sections dans le fichier de configuration et remplissez-le de suites d’exécution. Chaque suite doit avoir un tableau de navigateur avec des noms de navigateur ou une configuration d’aide au pilote :

Vous pouvez utiliser les paramètres grep et outputName pour filtrer les tests et le répertoire de sortie de la suite :

Ensuite, les tests peuvent être exécutés à l’aide de la commande run-multiple.

Exécutez toutes les suites pour tous les navigateurs :

codeceptjs run-multiple –all

Exécutez une suite de base pour tous les navigateurs :

codeceptjs run-multiple –basic

Exécutez la suite de base pour Chrome uniquement :

codeceptjs run-multiple –basic :chrome

Exécutez la suite de base pour Chrome et Smoke pour Firefox :

codeceptjs run-multiple –basic :firefox

Exécutez des tests de base avec grep et junit reporter :

codeceptjs run-multiple basic –grep signin –reporter mocha-junit-reporter

Exécutez des tests de régression en spécifiant un chemin de configuration différent :

codeceptjs run-multiple regression -c path/to/config

Chaque processus exécuté utilise un dossier personnalisé pour les rapports et les sorties. Il est stocké dans un sous-dossier dans un répertoire de sortie. Les sous-dossiers seront nommés au format suite_browser.

La sortie est imprimée pour tous les processus en cours d’exécution. Chaque ligne est étiquetée avec un nom de suite et de navigateur :

7. Rapport

Allure

Allure reporter est un outil pour stocker et afficher les rapports de test. Il fournit une interface utilisateur Web agréable qui contient toutes les informations importantes sur l’exécution des tests. CodeceptJS a un support intégré pour les rapports Allure. Dans les rapports, vous aurez toutes les étapes, sous-étapes et captures d’écran.

Allure nécessite Java 8 pour fonctionner. Ensuite, Allure peut être installé via NPM :

npm install -g allure-commandline –save-dev

Ajoutez le plugin Allure dans la configuration sous la section plugins.

Exécutez des tests avec le plugin allure activé :

npx codeceptjs run –plugins allure

Lancez le serveur Allure et voyez le rapport comme sur une capture d’écran ci-dessus :

allure serve output

9. Conclusion

CodeceptJS est un Framework mature sur lequel vous pouvez vous appuyer pour gérer vos outils d’automatisation de tests dans un environnement JS. Il fournit un support natif pour les objets de page, il a des outils pour gérer les données pour vos tests, prend en charge les tests dans plusieurs navigateurs (tests multi-sessions), enrichis les locateurs grâce à l’API de haut niveau et supporte les tests Framework connus. Ainsi que CodeceptJS peut également exécuter des tests mobiles avec Appium.

Voir aussi notre offre sur l’automatisation des tests.

Vous avez une question technique sur le sujet ? Vous avez un projet d’automatisation de test ?

Contactez-nous

Rédacteur : Mohamed Mortadha GUEDHAMI / Ingénieur Test Automation / All4Test