Idée

Les tests sont le point d'appui qui reste sur un code qu'on n'a pas écrit soi-même

Idée principale

Quelqu'un qui a écrit son code le tient par la mémoire : il sait ce qu'il a décidé, où il a pris un raccourci, quelles parties se touchent. Quand le code est produit par un assistant à raison de dizaines de commits par jour, cette mémoire n'existe pas. Il reste des écrans qui fonctionnent, un dépôt qu'on n'a pas lu en entier, et des parties qu'on ne saurait pas expliquer à voix haute.

Ce qui subsiste dans cette situation, ce sont les tests. Un projet monté en quelques jours peut en compter plusieurs centaines ; l'assistant les relance très souvent, et la plupart du temps rien ne casse. Quand quelque chose casse, le test ne dit pas seulement qu'il y a un problème : il dit quel comportement attendu n'est plus respecté, donc il localise, là où l'écran cassé ne fait que signaler.

Le test n'est donc pas ici un gage de qualité au sens habituel. C'est le seul instrument qui permet de conserver une prise sur un système dont on n'a pas la mémoire de construction.

Pourquoi c'est important

Cela change l'argument avec lequel on défend les tests auprès de quelqu'un qui ne code pas. « Les tests, c'est une bonne pratique » ne pèse rien face à la vitesse ; « sans eux, tu n'as aucun moyen de savoir ce que la dernière modification vient de casser dans un code que tu n'as pas lu » se comprend immédiatement.

Cela désigne aussi ce qu'il faut exiger en priorité d'un assistant à qui l'on confie la production : pas la couverture pour elle-même, mais l'existence d'un filet qui rende le système interrogeable après coup.

Nuances et limites

Le point d'appui n'est pas un contrôle. Les tests ne détectent que ce qu'ils décrivent : ils ne voient ni l'effondrement en volumétrie réelle, ni les défauts de sécurité, ni une architecture qui devient impraticable à faire évoluer.

Et l'exigence se dose. Un outil interne très simple, à faible risque et à durée de vie courte, n'appelle pas une stratégie de test complète — la question redevient celle de l'ampleur.

Questions ouvertes

  • Sur un code qu'on n'a pas écrit, comment savoir si l'ensemble des tests couvre les comportements qui comptent, plutôt que ceux qui étaient faciles à écrire ?