Les tests, qu’ils soient unitaires ou fonctionnels, se sont établis en tant que pratique incontournable des méthodes de développement modernes et sont en particulier un des piliers fondamentaux de l’agilité.
Si la pratique des tests a su s’imposer dans les workflows quotidiens des développements côté serveur (Sur les projets Django par exemple), elle a un peu plus de difficultés à se mettre en place dans les développements Javascript exécuté sur les navigateurs. Les frameworks MV* côté client (comme Angular), apparus relativement récemment ont hérité de l’héritage des bonnes pratiques actuelles et possèdent des frameworks de tests complets, mais nous allons nous attarder aujourd’hui sur un cas d’utilisation plus classique du Javascript: l’écriture de composants graphiques destinés à interagir directement avec le site, ce qui concerne beaucoup de plugins JQuery.
Voici comment ajouter une suite de tests à un plugin JQuery avec l’aide de quelques outils. Étant donné la richesse de l’écosystéme Javascript, il ne s’agit pas ici de donner la solution mais une solution parmi une multitude.
Mocha: le framework de tests
Mocha est non seulement le framework de tests qui va permettre d’écrire nos tests mais aussi l’outil qui va permettre de lancer ces derniers soit dans un navigateur, soit directement en ligne de commande avec la commande mocha.
Chai: une bibliothèque d’assertions
La bibliothèque d’assertions est utilisée pour faire les tests en eux même et fournit une syntaxe au développeur permettant d’exprimer des idées telles que « étant donné ces paramètres, cette fonction devrait renvoyer ce résultat ». Les assertions, que l’on retrouve plus habituellement intégrées directement dans le framework de test sont ici externalisées. Mocha en propose certaines, mais n’en recommande pas une en particulier par rapport a une autre. Nous avons ici choisi Chai, d’une par car c’est la bibliothèque fournie par défaut dans le générateur ‘webapp’ de Yeoman, mais aussi (et surtout) car elle fournie une syntaxe puissante et versatile, offrant au choix les possibilités de trois autres bibliothèques d’assertions (Should et Expect pour un style BDD, Assert pour un style TDD).
Exemple d’utilisation de Chai avec Expect:
var expect = chai.expect;
expect(foo).to.be.a('string');
expect(foo).to.equal('bar');
expect(foo).to.have.length(3);
expect(tea).to.have.property('flavors')
.with.length(3);
Les mocks avec Sinon
L’écriture de tests peut présenter des obstacles difficilement contournables lorsqu’il faut traiter du code côté client, on pensera notamment aux appels AJAX vers des services tiers, ou à certaines interactions utilisateurs difficilement reproductibles à l’aide d’appels $.trigger().
la bibliothèque Sinon peut résoudre ce type de problèmes en substituant, pendant la durée d’un test, un objet ou une fonction par un objet spécial qui a la possibilité d’être inspecté, de renvoyer des valeurs prédéfinies et de ne pas appeler une partie du code difficilement testable. Sinon est un équivalent de ce qu’on peut trouver dans le monde Python avec Mock.
Couverture de code avec Blanket
La couverture de code peut être un bon indicateur pour savoir si son code est suffisamment testé et surtout vérifier que certaines parties critiques sont bien exécutées. Blanket est un module Javascript compatible avec Mocha qui va créer des rapports de couverture de code suite au lancement des tests.
Rassembler tout le monde avec Grunt
Nous venons de voir un nombre conséquent de modules et d’outils permettant de mener a bien nos tests fonctionnels frontend. Cependant mettre tout cela en place, configurer chaque composant correctement peut s’avérer une tâche fastidieuse. Heureusement pour nous, des plugins pour Grunt on déjà fait ce travail à notre place et il suffira des les intégrer à un projet existant pour profiter des outils exposés ci dessus. Le plugin qui nous intéresse particulièrement est grunt-blanket-mocha. Il intègre en un seul paquet Mocha, Chai,PhantomJS et Blanket (Sinon est à rajouter si nécessaire). La mise en place de ce plugin n’étant pas triviale (il faut écrire un fichier HTML pour lancer les tests), rien de mieux que se baser sur un projet existant en provenance du même auteur: backbone.geppetto.
Automatiser l’intégration continue
En termes d’intégration continue, la solution la plus courament utilisée est d’utiliser Jenkins. Cependant, pour les projets Open Source (ce qui est souvent le cas pour les plugins JQuery) il existe une solution plus simple avec TravisCI. La seule contrainte est que le code soit hébergé sur github et qu’une configuration minimale soit renseignée afin d’indiquer comment lancer les tests.
De la même manière, il est possible de calculer la couverture de code avec le service Coveralls, lui aussi lié à Github.
Pour conclure
La quantité d’outils exposés ici afin de réaliser ses tests peut intimider, ces pratiques de test ne sont pas encore systématiques auprès des développeurs frontend et la majorité des outils montrés ici sont encore jeunes et doivent gagner en maturité. Cependant, il est aujourd’hui nécessaire d’apporter toute son attention à la qualité de son code Javascript. Nous ne sommes plus à une époque où Javascript apportait des fonctionnlités sympathique mais dispensable aux pages web, il n’est maintenant pas rare qu’un site (nous parlerons plutôt d’application dans ce cas) ne soit plus du tout fonctionnel sans Javascript.
La même attention doit être apportée dans le code frontend que dans le code backend et le seul moyen de s’en assurer passe par l’écriture de tests en s’équipant de bons outils.
Cet article Tester ses composants frontend est apparu en premier sur WSB agency.
