Chez Poplee Core RH nous avons décidé de mettre en place une stratégie de tests : unitaires d'API mais aussi end-to-end. Pour les tests end-to-end (ou E2E): d'abord en Selenium, puis un beau jour... Avec Playwright et Specflow !

Poplee Core RH est notre logiciel de gestion des données du personnel.

SpecFlow et Playwright

Qu'est-ce que Specflow ?

Specflow est un framework de test gratuit et open source, construit pour les technologies .NET. Il permet de faire des tests "Behavior Driven Development" (BDD) et utilise le langage Gherkin. Celui-ci repose sur trois mots-clés :

• "Given": définir les prérequis du test
• "When" : définir une action à réaliser
• "Then" : définir le résultat attendu

Ce langage permet d'écrire des tests compréhensibles par les PO et les développeurs, avec une syntaxe commune, claire. Un peu déroutant au début, on s'habitue rapidement à cette syntaxe, et cela devient plaisant et bien plus simple pour relire les tests.

Mais comment des phrases peuvent tester, produire du code de test ? Specflow c'est juste pour écrire des plans de test à réaliser par les PO ?

Un fichier de features est composé d'un ou plusieurs "Scénario". Chaque scénario est un ensemble de phrases, écrites selon le langage Gherkin.

Derrière chaque phrase de notre scénario de test, un mapping est fait avec des méthodes codées dans ce que l'on appelle des "Steps" (qui sont simplement des classes C#). Le mapping est possible grâce aux attributs [Given("...") ], [When("...") ], [Then("...") ] mis au-dessus de la méthode correspondante.

"Steps" et "features" mis ensemble forment nos tests, qui pourront être lancés dans notre éditeur de code.

Pour en savoir plus sur l'écriture de tests Specflow, vous pouvez lire l'article : Retour d'expérience sur SpecFlow

Qu'est-ce que Playwright ?

Playwright est une librairie de test open-source, compatible avec tous les navigateurs et le mobile. Playwright souhaite concurrencer le dinosaure Selenium, né en 2004. Si Selenium est un géant qui permet de pratiquement tout tester, il souffre de lenteurs et d'une difficulté d'utilisation... Pour le jeune Playwright, les mots d'ordre sont Modernité, Fiabilité et Facilité d'utilisation.

Il est possible d'écrire les tests en Javascript, Typescript, Python, Java et C#. Dans notre équipe ce sera, comme le reste du code, du C# !

La documentation est bien faite, et permet de choisir le langage que vous souhaitez pour voir divers exemples.

L'installation dans votre IDE préféré est très simple :

npm i -D @playwright/test  
# install supported browsers  
npx playwright install

Ensuite, de nombreuses méthodes de la librairie vous permettent d'interagir avec votre page : clic sur un bouton, écriture d'un texte, ouverture d'une modale… Tout ce dont vous avez besoin !

Exemples de code

Cliquer sur un élément

public async Task ClickingOnAsync(string selector)  
{  
  var page = _scenarioContext.GetPage();  
  
  await page.ClickAsync(selector);  
}

Vérifier que la page contient un certain texte

public async Task PageShouldContain(string text)  
{  
  var page = _scenarioContext.GetPage();  
 text = _scenarioContext.ReplaceAnyScenarioValues(text);  
  
  var element = await page.WaitForSelectorAsync($@"//*[contains(text(),""{text}"")]");  
  
 element.Should().NotBeNull($"Expected page to contain {text}");  
}

Ecrire un test E2E

Pourquoi faire des tests E2E ?

On peut citer trois principales raisons à l'écriture de tests end-to-end:

• Tester une nouvelle fonctionnalité de bout en bout
• Vérifier la non-régression de modules déjà existants
• Tester des scénarios critiques, qu'il n'est pas possible de tester "à la main". Parfois il n'est pas possible de tester autrement qu'avec un test E2E. Par exemple si on veut tester que 2 (ou plus) APIs interagissent bien entre elles, mais appartiennent à 2 (ou plus) systèmes / codebases différents, c'est impossible via des tests unitaires ou partiellement mockés.

Chez Core RH c'est cette dernière raison qui a principalement motivé l'écriture des tests E2E. En effet nous avons plusieurs scénarios critiques, qui s'appuient sur plusieurs systèmes à la fois, comme le module des Users qui est dans le projet Monolithe et les Contrats dans le projet Directory. Ou encore le module génération de documents qui fait intervenir plusieurs systèmes différents.

Comment utiliser Specflow et Playwright au sein des tests ?

Vous vous souvenez un peu plus haut, lorsque je parlais de tests specflow... Nous avions des fichiers de features avec nos scenarios en Gherkin, et des classes C# avec les méthodes correspondantes aux phrases de nos scénarios. Pour faire communiquer Specflow et Playwright, on remplace nos méthodes de test d'API, par des méthodes utilisant la librairie Playwright.

C'est toujours grâce aux attribus Given, Then ou When en haut de notre méthode Specflow que l'on map nos instructions de features SpecFlow avec nos méthodes Playwright.

Construire et debugger

Construire des tests en quelques secondes

Playwright a développé l'outil codegen, qui permet de générer du code de test en interagissant directement avec le navigateur. La ligne de commande suivante permet de lancer l'outil sur la page de Wikipedia. A chaque interaction avec la page, le code correspondant (ici en node.js) est écrit à droite.

playwright codegen wikipedia.org

C'est un très bon outil pour débuter, afin de comprendre mieux comment fonctionne Playwright. On ne peut pas vraiment obtenir des tests très complexes, mais cela permet d'obtenir déjà de petits tests simples.

Debugger ses tests

Débutant comme expert dans l'écriture de tests E2E avec Playwright, vous aurez forcément besoin de debugger vos tests. Playwright vous permet de voir vos tests se jouer en vidéo, comme si vous le faisiez vous-même à la main.

Vous pouvez voir ce que le test fait, où est ce que cela peut bloquer, et ainsi facilement corriger vos tests. Au début il peut être difficile de trouver les bons sélecteurs dans votre page. Mais pas de panique, pour cela vous pouvez aussi utiliser codegen ;)

Intégrer

Chez Lucca, il est possible dans github de lancer vos tests end-to-end à tout instant grâce à la recette automatique ! Pour cela il suffit de commenter la Pull Request avec un certain emoji (:man_cook: ou :woman_cook:). Une instance de preview est montée, afin d'y jouer les tests E2E. Lorsque les tests ont été effectués, le résultat est disponible dans la Pull Request, avec un rapport détaillant le résultat de tous les tests.

Nous avons également un channel Slack où il est possible de suivre l'avancement de la recette automatique.

REX chez Poplee Core RH

Temps de prise en main

La prise en main est assez rapide. Pour découvrir Playwright x Specflow et écrire plusieurs tests E2E dans des cas assez complexes, il faut quelques jours à une semaine. Après cette phase d'apprentissage, il est possible d'écrire des tests E2E en une demi-journée.

Avantages

• Une prise en main facile
• Moins de flaky tests
• Tests plus rapides qu'avec Selenium
• Il suffit de quelques instants pour pouvoir lancer les tests E2E d'un nouveau projet : build le projet, installer playwright en une ligne de commande et voilà les tests peuvent être lancés.
• Un debuggage des tests plus simple et efficace car très visuel
• C'est un framework Javascript, et peut donc également intéresser les fronteux !

Et l'avantage d'écrire des tests tout court...

• Le test des scénarios critiques est possible et facile
• La prévention des régressions est plus efficace
• Prendre l'habitude de coder des tests permet au développeur de repérer des erreurs avant même d'ouvrir sa Pull Request

Inconvénients

• Les tests sont souvent longs à être joués sur Visual Studio (un peu plus rapides sur Rider)
• On ne peut pas lancer des recettes automatiques à chaque build car cela prend beaucoup de temps et de ressources.

La suite ?

Nous avons une centaine de tests E2E dans notre projet Directory dont 35 utilisant Specflow et Playwright. Nous en ajoutons au fil de nos nouveaux développements, ce qui représente environ un rythme de 2 nouveaux tests par mois.

Pourquoi pas partager un certain nombre de steps dans une librairie partagée par l'ensemble des softs de Lucca ? En effet nous avons codé beaucoup de méthodes qui pourraient être utilisés dans d'autres équipes. Cela permettrait, peut-être, de convaincre plus facilement les équipes à nous rejoindre dans l'aventure des tests E2E !