Idée principale

Écrire le test d'abord et le code ensuite inverse l'ordre habituel, mais l'intérêt n'est pas dans l'ordre. Le test décrit le quoi — voilà le comportement attendu, voilà ce qui doit rester vrai. Le code décrit le comment. Le premier est donc une pièce de la spécification, écrite dans un langage que la machine peut évaluer.

Ce que cela change se voit dans la durée. Le code sera refactoré, il rencontrera de nouvelles données, d'autres fonctionnalités s'ajouteront autour de lui. Le comportement attendu, lui, est fixé ailleurs que dans la mémoire de celui qui l'a implémenté : s'il est cassé, le test casse, idéalement sur le poste du développeur ou en qualification plutôt qu'en production.

Le TDD ne supprime pas les défauts, ne remplace pas la réflexion produit, et ne transforme pas une mauvaise spécification en bon produit. Il fait une seule chose, et elle est peu commune : il rend une partie de la qualité vérifiable avant que le code existe.

Pourquoi c'est important

Cela sort la discipline du registre de l'hygiène technique. Un test écrit avant est un artefact de spécification, donc un endroit où le produit et le développement peuvent se mettre d'accord sur un comportement — ce qu'un document en prose ne permet pas, faute d'être évaluable.

Cela déplace aussi le coût des tests : écrits après, ils constatent ce que le code fait ; écrits avant, ils contraignent ce qu'il devra faire.

Nuances et limites

La partie formalisable est étroite. Un test dit qu'un comportement est tenu, jamais qu'il était le bon comportement à viser — la portion de qualité qui relève du jugement produit reste entière.

Et la discipline suppose qu'on sache énoncer le comportement attendu. Devant une spécification trop floue, écrire le test d'abord ne clarifie rien : il fige l'ambiguïté au lieu de la trancher.

Questions ouvertes

• Quelle part des comportements attendus d'une fonctionnalité est réellement exprimable en test, et que devient la part qui ne l'est pas ?