Introduction

Cet article fait suite au retour de HoppR sur le DevFest 2024 et se concentre sur la conférence de Lise QUESNEL qui aborde les outils de tests JavaScript.

Pour être concis, je vous résume les points qui m'ont le plus intéressés et ne reprendrai pas toutes les métaphores utilisées dans sa conférence. Bref ! Re-déroulons le chemin de JS-Jungle ensemble !

Tester, c'est douter ?

Avant de rentrer véritablement dans la JS-Jungle, répondons au pourquoi ? Et oui, pourquoi tester ? Tester manuellement est une activité chronophage avec des résultats non répétables. Les forces des tests automatisés sont leur rapidité et leur répétabilité. Ces deux qualités diminuent la longueur des boucles de feedback que ce soit en local, en pipeline de CI/CD ou même en recette.

Et en quoi réduire la longueur des boucles de feedback est intéressant ? Plus l'erreur est détectée tard dans la chaîne de valeur, plus elle sera coûteuse à réparer (Localisation, recontextualisation, etc). Associé à de petites incrémentations, tester permet de délivrer de la valeur plus rapidement toute en augmentant la qualité. De mon point de vue, il est aussi l'occasion d'augmenter la confiance entre les différentes parties prenantes (développeurs, PO, QA, etc) pour, à terme, diminuer la pression au quotidien.

Les typologies d'outils de test

Il est nécessaire de comprendre les différentes typologies car elles ne doivent pas être utilisées toutes en même temps. Chaque contexte a son besoin.

Les lanceurs (Test runner)

Leur but est d'exécuter les tests et d'exporter leurs résultats.

Exemple: Karma

Les structurateurs

Leur but est de structurer l'écriture des tests pour facilité leur lisibilité, écriture et maintenance.

Les deux syntaxes, aussi appelées modèles de tests ou patterns, les plus connues sont AAA (Arrange Act Assert) et Gerkhin (Given When Then). Toutes les deux expriment un contexte, une action puis des conséquences. Gerkhin se distingue par son approche comportementale des sujets métiers. Cela permet notamment d'obtenir un nommage/langage commun compréhensible par les développeurs et le métier.

Exemple: Cucumber

Les utilitaires

Leur but est de vérifier les attendus et de lever des exceptions claires. Cette notion est appelé "Assertion".

Exemple: Chai

Les spies, stubs et mocks

Leur but est d'isoler la partie du code testée par la simulation du fonctionnement de ces dépendances ou encore l'analyse à l'appel de ces dépendances.

Exemple: Sinon

Les multi-typologies

Si vous ne vous sentez pas d'avoir trop de dépendances dans votre projet, il existe aussi des outils couvrants toutes ces typologies :

Exemples:

• Jest
• Vite
• Jasmine

Les contrôleurs de navigateurs

La typologie des contrôleurs de navigateurs est à part dans le sens où leur but est de simuler un comportement utilisateur au plus proche du navigateur. Il y a 3 manières de contrôler un navigateur :

• Via ces drivers : Selenium
• Via script JS : Cypress
• Via API Native : Playwright ou Puppeteer

Les tests bancals

Si vous avez déjà commencé vos premiers tests, vous tomberez sur des tests bancals (Flaky en anglais) dont le résultat n'est pas répétable de manière certaine. Un jour il passe, l'autre non...

Un élément de réponse pour comprendre pourquoi il ne passe pas tout le temps est que le test est basé sur “quelque chose” de variable. Dans certains cas, pour contourner cette variabilité, nous pouvons simuler (mocker) ou remplacer l’élément variant.

Exemple:

• Lecture d'un tableau de données dans un ordre non déterministe
• Modification des données par un test précédent
• Appel à une date relative (Aujourd'hui, demain, hier)
• Sélecteur CSS non sûr (Vous pouvez utiliser les rôles: Testing-library) Des conseils pour garder une base de tests saine et, en conséquence, une confiance envers vos tests:
• "N'hésitez pas à mettre vos tests bancals en quarantaine"
• "Mettez des règles sur vos quarantaines (Nombre de jours maximums en quarantaine, nombre de tests maximum, etc)"
• “De manière générale, respectez les principes FIRST” Il existe des questions ouvertes que sont l'unité d'un test unitaire, la sociabilité des tests ou l'utilité d'un test qui sont en fait des sujets exploratoires. Si vous êtes totalement perdu, les langages front étant orientés composant, il est plus simple de prendre comme unité par défaut le composant (attention, simple n'est pas facile). Pour explorer ces notions, vous pouvez essayer le test-first ou encore le test driven developement.

Les stratégies de tests

Vous trouverez dans la JS-Jungle de nombreux noms de tests (unitaire, intégration, bout en bout, acceptance, composants, contracts, etc). Leurs significations varient en fonction des équipes, ce sont vos collègues qui vous expliquerons, au mieux, leur vision.

De manière simplifiée, nous dirons que nous avons des tests unitaires pour les fonctions utilitaires, des tests d’intégration pour les composants et des tests de bout en bout pour simuler le comportement utilisateur. Plus vous vous rapprochez des tests unitaires, plus vos unités de test sont fines et rapides mais moins vous pouvez avoir confiance en ceux-ci seules.

La question finale sera donc lesquels utiliser et en quelle proportion ? Vous trouverez de nombreuses distributions de tests : la pyramide, l'alvéole, le trophée. L'orientation des langages front modernes pousse vers l'utilisation de la distribution en trophée (Plus de tests de bout en bout que de tests unitaires et moins de tests de bout en bout que de tests d'intégration).

Ouverture

J'aimerais insister sur l'analyse statique de votre langage. Même si ce n'est pas un test en soit, le fait de typer, de créer des interfaces pour vos échanges, cela vous aidera à donner de la confiance en votre code et même à visualiser les sujets métiers.

Enfin, les tests manuels ne sont pas à bannir. Ils ne sont pas adaptés pour garantir la non-régression. Par contre, leur flexibilité est avantageuse pour des sujets exploratoires (Nouvelles erreurs, cas à la marge, etc). Peut-être devrions nous les appeler “tests exploratoires” ? A vous d'y répondre et de continuer de délivrer de la valeur pour vos utilisateurs et clients !

Merci de votre lecture et merci aussi à Lise QUESNEL pour son talk ! J'en profite pour la féliciter pour la qualité de la narration et de son écriture. N'hésitez pas à regarder la rediffusion de cette conférence.