Un regard neuf sur les tests de projets Node.js : 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 un 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 bons et loyaux services, j’ai décidé d’abandonner Expresso pour donner une chance à Mocha. Et puisque je m’étais habitué aux quelques petites fonctions dont Expresso enrichit le module assert, il m’a fallu 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 auteur 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 les noms 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 doute 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’outil 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. 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 :

describe 'Mon test', ->

    it 'doit être synchronisé', () ->
        # do sth

    it 'doit être asynchronisé', (next) ->
        # do sth
        next()

Il est intéressant de noter comment Mocha découvre et vous laisse décider pour chaque test si celui-ci 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 :

should = require 'should'
mecano = require 'mecano'
describe 'download', ->
    @beforeEach (next) ->
        mecano.mkdir scratch, next
    @afterEach (next) ->
        mecano.rm scratch, next
    it 'should deal with ftp scheme', (next) ->
        @timeout 10000
        mecano.download
            source: 'ftp://ftp.gnu.org/gnu/glibc/README.glibc'
            destination:  "#{scratch}/download_test"
        , (err, downloaded) ->
            should.not.exist err
            downloaded.should.eql 1
            next()

Les fonctions beforeEach et afterEach permettent l’exécution d’un code avant et après chacun des tests. La fonction timeout modifie le 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 que j’attends de ce type de librairie, ne pas avoir à ouvrir mon navigateur toutes les 5 minutes pour chercher comment utiliser ce satané API. Après 10 minutes d’utilisation, Should s’est avéré être simple, à la hauteur de ses ambitions et simplifie la lecture des tests, du 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 quinzaine de minutes. Faire en sorte que cette petite image soit verte me prit 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ées. Une autre erreur était due à ce que différentes versions 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éparer Travis de telle manière que le compte utilisateur peut faire un SSH sur lui-même sans mot de passe. A la fin, mon fichier “.travis.yml” de configuration fut le suivant :

language: node_js
node_js:
  - 0.6
  - 0.7
before_script:
  - "ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''"
  - "cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys"

Au cours de cet article, je n’ai pas fourni 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.

Partagez cet article