Soirée SFEIR : la question des tests


Tous les mois, les membres du pôle front (et d’autres !) de SFEIR se retrouvent pour la «bouffe front» afin de faire partager des side projects, des technologies ou des retours d’expérience. Pour cette édition de décembre 2015, c’était au tour de Siegfried Ehret et d’Alexandre Barbier de faire des présentations, axées sur les tests.

 

Nock et cucumber

Quand on fait des tests, il faut souvent plusieurs versions de fichiers de configuration (par exemple pour pointer sur un serveur de mock au lieu de l’API que l’on souhaite appeler). En plus, les API tierces sont comme les utilisateurs : ils peuvent faire ce qu’on n’attend pas et avoir un comportement qui peut entraîner un mauvais fonctionnement. mock permet de s’affranchir de tout ça en interceptant les appels http(s) et en renvoyant des résultats sur lesquels nous avons les pleins pouvoirs. Cet outil est particulièrement adapté pour les tests unitaires qui doivent passer en tout temps.

Ensuite, nous découvrons cucumber, qui permet d’écrire des scénarios de tests en masquant la complexité du code, le rendant ainsi compréhensible par les personnes non techniques impliquées dans un projet. Le but ultime : une fois toutes les règles cucumber implémentées côté développeur, si les PO / chefs de projets ont bien écrit les tests, on pourrait quasiment faire un copié-collé !

Les slides sont disponibles ici, un repo avec des exemples est disponible ici.

Tester un module node avec tape & sinon

Les environnements de test unitaires en JavaScript peuvent parfois s’avérer trop lourds à mettre en place pour dans le contexte de modules node. Le découpage en modules minimalistes, spécialisés dans une tâche spécifique et pouvant s’interfacer facilement avec d’autres modules est une tendance de fond, facilitée par npm. Cependant, les outils de tests unitaires traditionnels tels que Mocha ou Jasmine sont plus adaptées à des projets de taille importante et nécessitent beaucoup de configuration.

Il existe une alternative : tape, un outil de test qui produit un rapport d’exécution au format TAP (test anything protocol). L’API est minimaliste et permet de se concentrer sur la logique des tests plutôt que sur le boilerplate et la configuration. Les tests asynchrones sont gérés par défaut. De plus, il existe de nombreux reporters permettant de faciliter la lecture des résultats des tests ou bien de les interfacer à d’autres systèmes, comme de l’intégration continue.

Une technique intéressante est d’utiliser des stubs avec sinon sur les modules importés avec require. Cela permet de tester unitairement son propre module en simulant les comportements attendus des autres modules.

Les slides sont disponibles ici, un repo avec des exemples est disponible ici.

Il est temps de faire un mini-break avant de préparer les bouffes de 2016 !

Vous aimerez aussi...