Test-Driven Development

1Le cycle rouge, vert, refactor

Toute la méthode tient en trois temps répétés à l'infini :

1. Rouge : écrivez un test qui échoue ;
2. Vert : faites-le passer le plus vite possible, par n'importe quel moyen, même sale ;
3. Refactor : nettoyez le code sans rien casser.

// 1. ROUGE : on écrit le test AVANT le code
test('5 + 3 = 8', () => expect(somme(5, 3)).toBe(8))  // ✗ somme n'existe pas

// 2. VERT : le code le plus bête qui passe, même en dur
function somme(a, b) { return 8 }                       // ✓ honteux, mais vert

// 3. REFACTOR : un 2e test casse le "8 en dur", on généralise
function somme(a, b) { return a + b }                   // ✓ propre, toujours vert

La règle qui fait mal : pendant la phase deux, tout est permis pour obtenir le vert (même return 8 en dur), mais seulement le temps d'y arriver. Beck l'écrit : « le vert rapide excuse tous les péchés. Mais seulement pour un instant. » On ne refactorise jamais sur du rouge, et on ne laisse jamais une duplication derrière soi. La phrase de Ron Jeffries résume le but du livre en quatre mots : du code propre qui marche.

2Écrire le test d'abord, c'est concevoir

Le test n'arrive pas après le code, il arrive avant la classe elle-même. Beck commence par écrire ce qu'il voudrait pouvoir taper, comme s'il racontait l'usage parfait depuis l'extérieur : « quand on écrit un test, on imagine l'interface parfaite pour notre opération ». Son tout premier test crée un objet Dollar qui n'existe pas encore :

public void testMultiplication() {
    Dollar five = new Dollar(5);
    five.times(2);
    assertEquals(10, five.amount);
}

Ce test ne compile même pas : quatre erreurs (pas de classe Dollar, pas de constructeur, pas de méthode times, pas de champ amount). Beck les corrige une par une. L'erreur de compilation n'est pas un échec, c'est la première étape normale. Le test a dessiné l'API avant qu'une seule ligne de logique existe.

3« Fake it » : trichez pour démarrer

La technique la plus contre-intuitive du livre. Pour passer au vert au plus vite, retournez une constante en dur. Le test veut 10 ? Écrivez return 10. Barre verte. Puis, et c'est là le génie, rendez la triche visible : 10, c'est 5 fois 2, donc écrivez amount = 5 * 2. Maintenant la duplication saute aux yeux : le 5 et le 2 sont à la fois dans le test et dans le code. Pour l'éliminer, vous remplacez les constantes par des variables, étape par étape, jusqu'à amount = amount * multiplier. C'est l'élimination de cette duplication entre le test et le code qui force la généralisation, pas une décision abstraite prise dans votre tête. Vous ne réfléchissez pas au code général : vous l'obtenez en supprimant la copie.

4Trianguler : généraliser avec deux exemples

Quand vous ne voyez pas du tout comment généraliser, ajoutez un deuxième test qui rend la triche impossible. Pour tester l'égalité de deux Dollar, un seul test (5 égale 5) se contente d'un return true. Ajoutez « 5 n'égale pas 6 », et la constante ne tient plus : vous êtes forcé de comparer vraiment les montants. Beck appelle ça la triangulation : « ne généralisez que lorsque vous avez deux exemples ou plus ». Mais il est honnête sur son propre usage : « je n'utilise la triangulation que quand je suis vraiment, vraiment incertain de la bonne abstraction ». Ce n'est pas l'outil par défaut, c'est le filet quand on est perdu.

5La liste de TODO comme volant

Avant d'écrire le premier test, Beck note tout ce qu'il faudra tester sur une liste. L'item en cours est en gras, l'item fini est barré. Quand une idée surgit en plein cycle (un cas limite, un refactoring à faire), il ne la traite pas tout de suite : il l'ajoute à la liste et reste concentré sur sa tâche en cours. La liste, c'est sa mémoire de travail posée sur la table : elle garde le focus sur une seule chose à la fois, et elle dit quand on a fini, quand elle est vide. Le TDD, dit-il, est un processus de pilotage : un peu à gauche, un peu à droite, jamais un grand plan figé d'avance.

6Le TDD, c'est gérer la peur

C'est la vraie thèse du livre, celle que ses imitateurs ont oubliée. « Le développement piloté par les tests est une façon de gérer la peur pendant qu'on programme. » Le stress crée un cercle vicieux : plus vous avez peur de casser, moins vous testez, plus vous introduisez de bugs, plus vous avez peur. Le TDD coupe la boucle. Beck le dit franchement : « plus je ressens de stress, plus je lance les tests ». La barre verte n'est pas qu'un voyant : c'est une dose de calme. Sa formule la plus belle : les tests sont la pierre philosophale du programmeur, ils transmutent la peur en ennui. Pas l'ennui de s'embêter, l'ennui tranquille de quelqu'un qui sait que rien ne va exploser.

7xUnit : l'arbre dont descend tout le testing moderne

La deuxième partie est vertigineuse : Beck construit un framework de test en l'utilisant pour se tester lui-même. Au tout début, le framework n'existe pas, alors il vérifie à la main, puis, dès que la classe TestCase tient debout, il lui fait tester sa propre exécution. De ce bootstrap sortent les briques que vous connaissez sans le savoir :

• setUp et tearDown : chaque test part d'un état propre et indépendant ;
• TestSuite : regroupe des tests et se manipule comme un seul ;
• TestResult : compte les succès et les échecs.

Martin Fowler a résumé l'affaire : jamais dans l'histoire du génie logiciel autant de gens n'ont autant dû à aussi peu de lignes de code. JUnit, pytest, Jest, PHPUnit : tous descendent de cette poignée de classes.

8Les limites, dites par l'auteur lui-même

Ce qui rend le livre crédible, c'est que son auteur refuse de survendre. Beck pose lui-même les questions qui fâchent dans le dernier chapitre :

• Le TDD est-il prouvé ? « Non. Aucune étude n'a démontré catégoriquement de différence entre le TDD et ses nombreuses alternatives, en qualité, en productivité ou en plaisir. »
• Le code legacy ? « Le plus gros problème, c'est que du code écrit sans penser aux tests est en général très peu testable. »
• La taille des pas ? Pas de réponse unique : il faut savoir faire des petits pas ET des grands, et choisir selon sa confiance du moment.

Et il relativise tout : « une bonne ingénierie, c'est peut-être 20 % du succès d'un projet ». C'est l'inverse d'un gourou.