Soirée “Les Tests en JS” – Le retour

Le 27 novembre, nous organisions (avec mes camarades Lionel et Simon) un after-work sur le testing Javascript et plus particulièrement l’approche TDD/BDD.

Nous voulions, tout d’abord, dire un grand merci à tous les participants d’être venus, d’avoir participé activement et d’être restés jusqu’à la fin ! 😉 Pour ceux qui n’ont pas pu être parmi nous, voici ce dont il retournait :

La soirée s’est déroulée en 3 parties : Intro, TDD et BDD.

Introduction

Nous avons débuté par un petit rappel sur l’historique du langage, comment il était utilisé et comment il a évolué jusqu’à aujourd’hui. Nous avons ensuite fait le tour des frameworks les plus connus en comparant leurs avantages/inconvénients et donc pourquoi il est maintenant plus facile et pertinent d’appliquer le testing, tel qu’on le connait, au JS. Cela nous a conduit au développement de deux approches qualitatives que sont le TDD et le BDD qui permettent, entre autres, d’avoir une spécification à jour avec le code ! Nous avons également discuté des différents types de tests que l’on rencontre le plus fréquemment (Unitaires, Service, UI) et parlé d’architecture émergente avant de passer aux ateliers.

TDD

Simon a enchaîné directement sur une série d’exercices d’écriture de tests unitaires à la sauce TDD avec Jasmine et Karma sur un jeu de morpion que Lionel nous a dégoté tout en rappelant le cycle de développement qui va bien :

1. J’écris mon test et je teste -> ça fail !
2. J’écris juste ce qu’il faut pour faire passer mon test et je re-teste -> ça passe !
3. Je peux réécrire mon test et/ou en écrire un autre -> on repasse à l’étape 1. 😉

Ce qui nous amène à spécifier, implémenter et refactorer notre code et, par conséquence, à faire émerger une architecture spécifiée et sécurisée, côté développeur uniquement.

Nous avons aussi abordé d’autres librairies dont Mocha, Sinon, Chai, Sinon-Chai, etc.

BDD

En 3ème partie, nous avons vu une autre méthode de développement drivée, elle aussi, par les tests. Bien que basée techniquement sur du TDD, l’idée ici est de baser le développement sur le comportement (métier) de l’application pour en produire un pan (User Story). L’avantage de cette méthode est d’avoir un langage commun entre développeurs, testeurs et product owner/stakeholders et de qualifier des Features/User Stories.

Pour cela, nous nous sommes aidés de CucumberJS et son langage Gherkin (Given, When, Then) afin de spécifier les User Stories sous forme de fichiers « .feature » contenant plusieurs Scénarios (critères d’acceptation) chacun. CucumberJS permet même de générer les « step definitions » à partir des fichiers « .feature » qu’il détecte automatiquement. Cool !

Conclusion

Nous avons pu voir, au travers de ces exercices, qu’il est maintenant possible, plus simple et pertinent, d’apporter ce filet de sécurité que sont les tests au Javascript. Et c’est de plus en plus vrai avec les frameworks qui sont apparus ces dernières années comme Angular ou Durandal pour ne citer qu’eux.

Vous pouvez retrouver toutes les sources ici : https://github.com/Cellenza/TicTacToe. NodeJS est requis bien évidemment :p

Merci à tous et à la prochaine ! 🙂