De cette façon, j’obtiens donc forcément du code testable, donc du code qui respecte les principes fondamentaux de la programmation orientée objet tels que SOLID, Liskov et la loi de Demeter.

Par contre, je me rends compte encore régulièrement que ma façon d’écrire des tests n’est pas forcément la meilleure, notamment lorsque je lis de la littérature sur le sujet ou lorsque je modifie le code d’une de mes classes afin de l’optimiser et que les tests associés passent au rouge alors que le périmètre fonctionnel n’a pas changé.

Il est donc finalement normal qu’aujourd’hui, mes tests me donnent régulièrement envie de vomir, d’autant plus qu’il n’existe pas à ma connaissance de bible de référence ou de lois aussi absolue que SOLID ou Demeter en ce qui concerne leur rédaction.

Il y a certes de très bonnes sources d’inspiration, mais l’information est fragmentée et le vocabulaire est souvent fluctuant en fonction des sources, d’autant qu’en règle générale elles sont spécifiques à un outil de test particulier et n’embrassent pas l’intégralité du domaine du test.

Dans un tel contexte, celui qui souhaite améliorer la qualité de ces tests le fait donc en fonction de l’outil qu’il utilise, de l’expérience qu’il acquière en le manipulant et de ses lectures.

Le coefficient directeur de sa courbe d’apprentissage est donc relativement faible et elle est de plus relativement linéaire, car l’apprentissage est très progressif par rapport à celui d’une personne qui disposerait d’une bible de référence efficace pour appréhender un nouveau domaine d’expertise.

J’ai de plus remarqué deux autres facteurs expliquant l’amélioration de la qualité de mon code depuis que j’ai adopté le développement piloté par les tests.

Le premier est que cette méthode de travail oblige en effet à suivre les bonnes pratiques de la programmation orientée objet, sans quoi le code devient très difficilement testable de manière correcte, c’est à dire avec un taux de couverture suffisamment significatif.

Et comme l’une de ces bonnes pratiques est de découpler fortement les fonctionnalités, je passe donc par exemple parfois un temps négligeable à réfléchir à un nom adéquat pour mes variables, propriétés, fonction, classe et interface afin d’avoir une sémantique suffisante pour que mon code reste compréhensible pour celui qui le découvre, ce qui confirme que Phil Karlton a bien raison lorsqu’il dit que trouver un nom est l’une des deux seules choses réellement difficiles en informatique.

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton

Le second facteur est que je développe plus lentement qu’auparavant, indépendamment du fait que j’écris maintenant des tests en plus du code.

Le développement piloté par les tests m’oblige en effet, pour que je puisse rédiger mes tests, à réfléchir à l’architecture de mon code avant de l’écrire, au lieu de laisser émerger cette architecture de mon code et éventuellement de la corriger à postériori, au risque d’y introduire des bogues ou de provoquer des régressions.

Et même si les tests facilitent le processus, car ils mettent le code en situation d’exploitation, cela peut être un réel challenge, notamment dans le cas de fonctionnalités complexes.

De plus, les tests sont une mise en pratique du code, et ils encouragent donc le développeur à gérer correctement les cas d’erreur ou limite, soit parce que ces derniers surviennent lors de l’exécution des tests, soit parce que leur écriture l’y fait penser naturellement.

En conséquence, ma productivité quotidienne instantanée a donc baissé puisque je réfléchis beaucoup plus que par le passé lorsque je développe, mais mécaniquement, la qualité de mon code en est augmentée d’autant.

De plus, je suis persuadé qu‘assez paradoxalement, cette amélioration de la qualité de mon code m’a à contrario fait augmenter ma productivité moyenne, notamment parce que les tests me permettent de remettre en cause partiellement ou totalement le code que j’ai écrit en ayant la garantie de ne pas altérer son fonctionnement, sans parler du fait que les tests documentent mon code automatiquement.

Reste que je n’ai aucune donnée objective pour étayer ce qui n’est donc qu’une intuition, et que je ne sais pas comment les obtenir alors qu’elles me permettraient de démontrer l’intérêt des tests sans coup férir.