Pourquoi je ne teste pas ?

Tester son code est une étape primordiale quand on vise une base de code pérenne. Les tests permettent de détecter en même temps que le développement les éventuels bugs et régressions que les nouvelles fonctionnalités pourraient apporter. Mais écrire des tests, c'est long et c'est pas très rigolo, surtout quand on est développeur de guichet (front-end pour les non initiés à l'Académie Française). Et puis bon, je donne des leçons, mais moi aussi il m'arrive de ne pas tester mon code. Voici pourquoi.

Parce que j'ai pas le temps !!!!

Oui, souvent la date de livraison du projet est très courte et il faut aller très vite. Tester son code en live dans son navigateur, puis sur d'autres navigateurs est déjà très chronophage. Rédiger des tests avant d'être sur que le DOM généré sera celui qui correspondra à la maquette sur tous les navigateurs supportés peut aussi être une source de perte de temps. Oh et puis, on est agile, donc quand on commence un développement, il est très probable qu'avec l'agilité de la biche, on nous demande de changer des trucs en cours de route. Du coup, j'ai plutôt tendance à rédiger les tests à la fin. Mais à la fin, souvent, j'ai plus le temps parce qu'il fallait livrer hier.

Parce que c'est moche !!!!

Alors ici, c'est un argument vraiment typique du développeur front. Ce qui fait la différence entre un développeur de guichet et d'arrière guichet (back end), c'est sa sensibilité aux belles choses. Le backend lui, il s'en fout du rendu. Tant que sa donnée est correctement transformée comme il l'a décidé ou que sa commande agit tel qu'il le lui a ordonné, un terminal fera aussi bien l'affaire qu'un design léché. Et donc, finalement, les tests, c'est même carrément sexy pour lui. Le front dev, lui, il développe du design, du graphique, du visuel, de l'ergonomie, du feeling, des choses difficilement appréciable autrement qu'à l'usage. C'est d'ailleurs souvent pendant le développement qu'on se rend compte que certains détails de la maquette figée en jpg ne sont pas cohérents et qu'on fait alors appel aux instincts de biche du développeur pour modifier et améliorer la situation. Donc finalement, on est déjà en alternance entre dev et tests du simple fait d'aller voir le résultat de son dev sur son navigateur. Et une fois le résultat accompli, on est content de voir ces belles choses s'afficher et on a pas vraiment envie de doubler l'effort pour voir des trucs moches dans un terminal qui ne correspondent à rien de concret.

Parce que c'est compliqué !!!!

Cette fois, ça vaut aussi pour le dev d'arrière guichet, mais moins, car lui n'a pas vraiment le choix finalement. Il est obligé de passer par des tests s'il veut constater que son code fonctionne. Donc pour les raisons évoquée au dessus, le front dev arrive à se passer de tests, et donc, il en fait peu et donc n'apprend pas à en faire 😅 Et donc c'est compliqué, et paf, une nouvelle excuse ! Faut avouer aussi que ça ne s'apprend pas en claquant des doigts de déterminer quoi tester, comment le tester, savoir délimiter la portée de son test, savoir ce qu'est un mock, comment l'écrire, etc.

Parce que je suis le seul dev !!!!

Bah je dois déjà m'occuper tout seul de l'intégration, du SEO, de l'architecture front et puis aussi aider à l'infrastructure parce que AWS c'est pas si simple que le boss le pensait alors pfiou… je vais pas m'emmerder avec des tests. Oui certes, le jour où je me retrouve face à une régression, je vais encore perdre plus de temps, mais je suis certain que d'ici là on aura enfin embauché quelqu'un pour s'occuper du support !

Parce que je le vaut bien !!!!

C'est bien connu, celui qui teste doute. Moi je code comme un Dieu, j'ai pas besoin de test. J'ai vu mon dev fonctionner dans mon navigateur donc works4me. Si on vient me remonter un bug, c'est probablement parce qu'un autre dev est passé derrière et code moins bien, je vais plutôt aller lui donner des coups de fouets et l'insulter, ensuite, on pourra aller voir pourquoi ça merde sous IE depuis l'ajout de cette nouvelle fonctionnalité.

PARCE QUEEEEEEEEE

Dans les faits, il n'y a que peu d'excuses valables pour ne pas faire de tests. C'est plus naturel pour un développeur d'arrière guichet qui n'a pas beaucoup d'autre moyen pour constater que son code fonctionne. Pour un développeur de guichet, c'est le navigateur qui joue ce rôle et les tests sont une étape supplémentaire à rajouter au worflow qui est déjà très copieux. Cependant, les outils pour mettre en place les tests sont aujourd'hui fournis clé en main à l'aide d'un simple npm i. Il faut s'y mettre et prendre cette habitude. Même si parfois les circonstances font que c'est un peu plus compliqué. Il faut l'assumer et faire tout son possible (en tant que dev et en tant que manager) pour permettre d'améliorer la situation dans les projets futurs.

Hadrien

Hi, I'm a french Javascript Lead Developer, Web Architect from Toulouse, France. I've worked for 12 years for many projects with YUI, AngularJS, Aurelia.io and now React and React native.

Toulouse, France https://hadrien.eu