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, objet de page (Paje Object), 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.

Architecture-CodeceptJS

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é :

npx

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.

Features-fonctionalités

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 :

Scénarios

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 :

Scénario

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 :

Scénario

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.

Scénario

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 :

Scénario

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 :

Step-definitions

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:

npx

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

npx

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

npx 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 :

npx-tag

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’étapesconfigration-gherkin

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 :

Exemples-localisateurs

É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 :Injection-de-dependance

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 ().

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.

Acteur-etape-personnalissée

PageObject

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

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

Modèle-objet-de-page

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

Vous pouvez inclure cet objet de page 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 :

Scénario

Vous pouvez également utiliser async / wait dans PageObject :

Objet-de-page

Et utilisez-les dans vos tests :

Scénario

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 objet page en tant que classe :Objet-de-page-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 :

npx

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.

npx

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 :

configuration

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

grep-output-name

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 :

GitHub

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.

Rapport-Allure

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.

Plugin-Allure

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

8. Tableau de comparaison des outils

CodeceptJS Cypress Protractor WebdriverIO
Modern End 2 End Testing Framework for NodeJS. Il s’agit d’un cadre de test moderne de bout en bout avec une syntaxe spéciale de style BDD. Le test est écrit comme un scénario linéaire de l’action de l’utilisateur sur un site. Chaque test est décrit dans une fonction de scénario avec un objet I qui y est passé. Des tests meilleurs, plus rapides et plus fiables pour tout ce qui s’exécute dans un navigateur. Cypress est une application de test automatisée frontale créée pour le Web moderne. Cypress est construit sur une nouvelle architecture et s’exécute dans la même boucle d’exécution que l’application testée. En conséquence, Cypress fournit des tests meilleurs, plus rapides et plus fiables pour tout ce qui s’exécute dans un navigateur. Cadre de test de bout en bout pour les applications Angular et AngularJS « . Protractor est un cadre de test de bout en bout pour les applications Angular et AngularJS. Protractor exécute des tests sur votre application exécutée dans un navigateur réel, interagissant avec elle comme un utilisateur le ferait WebdriverIO vous permet de contrôler un navigateur ou une application mobile avec seulement quelques lignes de code. Votre code de test sera simple, concis et facile à lire. WebdriverIO est un outil de la catégorie Test de navigateur d’une pile technologique
2.33K GitHub stars and 401 GitHub forks 13.9K GitHub stars and 725 forks 8.29K GitHub stars and 2.27K forks on GitHub 5.8K GitHub stars and 1.7K GitHub forks
  • Behavior Driven Development
  • Acceptance Testing
  • Data Driven Tests
  • Acceptance Testing
  • Time Travel
  • Behavior Driven Development
  • Acceptance Testing
  • Lisibilité
  • Prise en charge de plusieurs navigateurs
  • Contrôle complet du navigateur
  • Open source
  • Communauté
  • Conducteur flexible
  • Facilitez-nous avec CI
  • Open source
  • Grande documentation
  • Utilisation simple
  • Vite
  • Test de navigateur croisé
  • Facilitez-nous avec CI
  • Npm install cypres uniquement
  • Installation facile
  • Implémentation de tests rapides
  • Open source
  • Promesse de soutien
  • Souple
  • Facilitez-nous avec CI
  • Diverses intégrations à des fournisseurs comme Sauce Labs
  • Facile à installer
  • Grande communauté
  • Open source
  • Petite communauté
  • Cypress est faible lors des tests inter-navigateurs
  • Changer d’onglet: Cypress ne peut pas prendre en charge
  • Pas de prise en charge de plusieurs domaines
  • Pas de support iFrame
  • Aucun support de téléchargement de fichier
  • Pas de support xPath
  • Cypress ne prend pas en charge l’application native
  • Réexécuter les tentatives de tests ayant échoué pas encore pris en charge
  • Pas de support d’objet de page
  • Pas de support pour le contrôle de plusieurs onglets
  • Pas de prise en charge pour le contrôle de plusieurs navigateurs
  • Il prend uniquement en charge javascript.
  • Il fonctionne très bien dans le navigateur Chrome. Il n’a pas beaucoup de support sur les autres navigateurs.
  • Le support de classe de robot n’est pas présent dans Protractor
  • Maintenance élevée

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