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 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 :
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
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}");
}
On peut citer trois principales raisons à l'écriture de tests end-to-end:
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.
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.
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.
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 ;)
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.
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.
Et l'avantage d'écrire des tests tout court...
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 !