De l’intérêt des tests
Étant donné que Atipik, la société qui m’emploie, recrute, je suis amené à faire passer des entretiens d’embauches. Parmi la multitude de questions posées et de points abordés, je ne peux m’empêcher d’évoquer la place des tests dans le travail du postulant, étant moi-même le principal rédacteur de la documentation française d’atoum, un contributeur modeste, un utilisateur quotidien et présent tous les jours (ouvrés) sur le chan ##atoum (oui, 2 « # ») du serveur IRC Freenode. La grande majorité m’indique qu’ils ont entendu parler des tests. Ça me fait toujours penser à une lointaine légende, un monde imaginaire qu’on évoque au coin du feu. Ils continuent presque tous, en disant que c’est en haut de leurs TODO listes et qu’ils vont s’y mettre c’est promis. Et à la question fatidique « mais pourquoi ne pas en avoir déjà fait ? », une réponse vient immédiatement et systématiquement : « pas le temps ».
Soyons clairs, je ne suis pas né avec un manuel « le test unitaire et fonctionnel pour les nuls » dans les mains et je n’ai clairement pas fait des tests toute ma vie. Au début, dans le monde PHP, il n’y avait que (l’horrible) PHPUnit et son écriture d’un autre temps (mais malheureusement répandue). Les tests étaient longs, fastidieux, pénibles et si je pouvais ne pas les faire, ma vie était meilleure. Puis mageekguy est arrivé avec son atoum, un framework de test unitaire moderne, simple et intuitif pour PHP 5.3+ et tout a changé dans ma vie de développeur.
Mais revenons à cet argument du temps. Le test fait-il vraiment perdre du temps ?
Au début, il faut changer ses habitudes et apprendre un (plusieurs) nouveau(x) framework(s). N’est-ce pas ce que l’on fait tout le temps en informatique ? La découverte d’une nouvelle technologie n’est-elle pas toujours accompagnée d’un temps d’apprentissage et de remise en question de nos connaissances ? Nous pouvons donc ignorer ce « temps perdu » puisqu’il est inhérent à toute nouvelle technologie et non aux tests en particulier.
Alors c’est l’écriture de tests qui ferait perdre du temps. Et à première vue, ça paraîtrait logique. Le temps que l’on met à écrire une ligne de test, on aurait pu le passer à écrire une ligne de code. Du moins, si vous estimez que les tests ne font pas partie de votre travail de développeur. Mais admettons. Sauf que c’est oublier que l’écriture de tests, particulièrement lorsqu’il dirige le développement comme lorsque l’on pratique le TDD ou le BDD (je vous laisse le soin de lire cet article qui compare le TDD au BDD et qui vous permettra de comprendre que ce n’est ni plus ni moins que la même chose), permet de mieux penser son code et fait, très souvent, gagner du temps plus qu’il n’en fait perdre. En revanche, c’est difficilement quantifiable et ça dépend également du niveau. Un débutant mettra plus de temps qu’une personne habituée à l’écriture des tests.
Puisqu’on ne peut pas vraiment quantifier le temps gagné, les tests ne servent-ils donc à rien ?
Penchons-nous quelques instants sur notre projet. Nous l’avons commencé il y a plusieurs mois, plusieurs années peut-être et, même en admettant que nous ayons écrit chaque ligne de chaque fichier de ce projet, il est totalement illusoire de penser qu’on en maîtrise parfaitement chaque fonction, en tout cas, pas au point de savoir prédire quelles sont les retombées de ce qu’on s’apprête à modifier. Par expérience, c’est toujours dans la partie du code la plus improbable, la plus éloignée de ce que vous venez de modifier que le bug se situera. Encore un coup de la loi de Murphy.
Et si, finalement, c’était dans ces moments-là que le temps gagné était le plus important ? Je fais ma modification, je lance les tests, je vois que ça plante dans tel fichier, je corrige, je relance les tests, tout est au vert et je peux mettre en production l’esprit tranquille.
Si vous ne voyez le test que dans le présent, alors vous pouvez le ranger à côté de tout un tas de méthodes de travail et d’aide au développement. C’est intéressant à utiliser, mais on peut raisonnablement se poser la question du taux efforts/résultats. En revanche, si vous vous projetez dans le futur et que vous voyez les tests comme une multitude de super héros qui vous accompagnent durant toute la vie de votre projet et qui sont les garants de la fiabilité de votre code, alors vous comprenez tout de suite que le test n’est pas une possibilité, mais une nécessité. Ce sont vos tests qui, demain, vont vous sauvez lorsque, en modifiant une méthode anodine dans une classe perdue au fond de votre projet, vous laisserez passer un bug monstrueux qui interdit à chacun de se connecter à votre site ou pire, qui permet d’accéder à la totalité de votre catalogue sans l’acheter.
Tout ce « temps perdu » vous en fera gagner tellement lors de l’écriture et surtout lors des futures modifications que vous ne voudrez plus revenir en arrière une fois que vous aurez goutté aux tests. Sans parler de la sérénité que vous aurez à faire des modifications, même profondes.
