Nouveau regard sur les tests en Node.js avec Mocha, Should et Travis

Suite à une demande, l’article ci-dessous est la traduction d’un précédent publié le 19 février 2012.

Aujourd’hui, j’ai finalement décidé de passer une peu de temps autour de Travis. Cette petite image verte en haut des pages d’accueil de projets GitHub m’intrigue de plus en plus ces derniers jours. En fait, pour être tout à fait honnête, ce n’est pas exactement ainsi que j’ai débuté ma soirée. Tout d’abord, après deux ans de bon et loyaux services, j’ai décidé d’abandonner Expresso pour donner une chance à Mocha. Et puisque je m’étais habitué aux quelques petites fonction dont Expresso enrichit le module assert, il m’a fallut y remédier, ce qui m’a conduit au module Should. Il me fut assez plaisant de voir comment ces deux derniers modules se complètent parfaitement l’un et l’autre, dans la plus pure tradition Unix: petit, puissant et bon citoyen.

Écrit par le même autheur qu’Expresso, Mocha est une alternative qui a pour objectif de le remplacer. Cette situation prévaut depuis plusieurs mois déjà mais je n’avais jamais trouvé un grand intérêt à passer dans le monde des tests de type BDD. BDD signifie Behavior Driven Development, soit le développement des tests en mettant en valeur les comportements. Ils s’opposent le plus souvent aux tests unitaires qui sont moins expressifs, et donc par la même moins verbeux. Par exemple le nom des tests sont exprimés comme des phrases entières. Le but est d’encourager la collaboration entres les développeurs et les personnes non techniques comme les intervenants business dans la conception de logiciels. Il existe sans doutes des projets et des cultures d’entreprises dans lesquels cela peut s’appliquer mais de mon expérience personnelle, il m’est impossible de faire participer mes clients dans l’expression des tests unitaires. Cucumber est probablement l’outils de BDD le plus populaire, ce fut l’un des premiers. Cet outil a ses inconditionnels mais j’ai toujours été bien trop fainéant par le passé pour sauter dans cet enfer. À en juger par les exemples, cela implique grossièrement l’apprentissage d’un nouveau langage juste pour écrire des tests. Cette impression est certainement mauvaise et il se peut toutefois que ce soit plus simple qu’il n’y paraisse.

Maintenant, regardons un peu comment s’utilise Mocha]mocha. L’API est relativement simple, principalement deux fonctions qui sont describe et it. Chacune prend un texte comme premier argument qui combinés ensemble forment une phrase visible à l’exécution des tests. Un exemple :

Il est intéressant de noter comment Mocha découvre et vous laisse décider pour chaque test si celui doit tourner en mode synchrone ou non, vous permettant de mixer les deux modes et rendant vulgaire l’option serial -s d’Expresso. Il fait en effet appel à la propriété pas si populaire qu’est length attachée à toute fonction. Il y a aussi d’autres méthodes qui sont utiles lors de l’écriture de tests pour modifier la configuration, aider à la mise en place et nettoyer les tests. À titre d’illustration, voici un exemple inspiré des tests de mecano:

Les fonctions beforeEach et afterEach permettent l’exécution d’un code avant et après chacun des tests. La fonction timeout modifie la temps d’exécution maximale d’un test (par défaut 2 secondes).

Maintenant, introduisons l’utilisation de Should. Son principe comme toute librairie d’assertion est de détecter des valeurs incorrectes. Au début, le style d’API de type BDD peut sembler compliqué mais je l’ai tout de suite trouvé naturel et je n’ai pas dû lutter contre lui. En fait, c’est bien là l’essentiel de ce dont j’attend de ce type de librairie, ne pas avoir à ouvrir mon navigateur toutes les 5 minutes pour chercher comme utiliser ce satané API. Après 10 minutes d’utilisation, Should s’est avéré être simple, à la hauteur de ces ambitions et simplifie la lecture des tests, dû moins selon mon opinion.

Finalement, j’ai décidé de m’occuper de Travis et de ces images de statut. Obtenir une image en haut de la page d’accueil de mecano sur GitHub fut facile. La mise en place grâce à son intégration avec GitHub est aisée et pour un nouveau venu prend une 15 de minutes. Faire en sorte que cette petite image soit verte me pris plus de temps. Mecano prend un peu de libertés quand il déroule ses tests. Il a besoin d’être en ligne, GIT doit être installé et il a besoin de se connecter en SSH sur lui-même. Dès la première passe sur Travis, je fus agréablement surpris en constatant que seulement 5 tests ne passaient pas. La plupart de ces erreurs étaient ma faute et furent aussitôt fixés. Une autre erreur était dû à ce que différentes version de Node.js étaient testées mais Should n’est pas compatible avec la version “0.4”. Cela me laissait avec un dernier problème, préparé Travis de tel manière que le compte utilisateur pour faire un SSH sur lui-même sans mot de passe. A la fin, mon fichier “.travis.yml” de configuration fut le suivant:

Au cours de cet article, je n’ai pas fournis d’instruction sur l’installation et la configuration de ses librairies mais chacun des projets est extrêmement bien documenté. Merci aux auteurs pour leur travail.

Par |2018-06-05T22:37:23+00:00March 3rd, 2012|Uncategorized|0 commentaire

À propos de l'auteur :

Passionné de programmation, de données et d'entrepreneuriat, je participe à façonner Adaltas pour qu'elle soit une équipe d'ingénieurs talentueux partageant leurs savoir-faire et leurs expériences.

Laisser un commentaire