Tu as écrit un test rouge. Et maintenant ?
À la leçon 5, tu as appris à écrire le test en premier, avant même que la fonction existe. Tu t'es retrouvé avec un rouge. C'est voulu. Mais la vraie question, c'est : que fait-on ensuite ? Et surtout, dans quel ordre ?
Le TDD (Test-Driven Development) répond en trois temps. Trois étapes, dans cet ordre précis, en boucle. C'est tout. Pas de magie, pas de cérémonie : un rythme. Et ce rythme te donne la boucle de feedback la plus courte du développement. Entre le moment où tu écris quelque chose et celui où tu sais si c'est juste, il ne se passe que quelques secondes.
La boucle TDD : RED (écris un test qui échoue) → GREEN (écris le minimum de code pour le faire passer) → REFACTOR (nettoie le code, tests toujours verts). Puis recommence.
Chaque tour de boucle peut durer quelques minutes. Tu valides en continu. Tu ne te demandes jamais « est-ce que ça marche encore ? » : les tests te le disent instantanément, à chaque tour.
Les trois étapes, règle par règle
1. RED : écris un test qui échoue
Avant d'écrire une ligne de code de production, tu écris le test qui décrit le comportement voulu. Ce comportement n'existe pas encore : le test passe donc au rouge. C'est normal, c'est le but. Un test rouge qui décrit quelque chose de réel est ton point de départ.
Règle stricte du RED : ne passe à l'étape suivante que si le test est vraiment rouge pour la bonne raison. Si tu lances le test et qu'il passe vert tout de suite (sans avoir rien écrit), c'est que le test ne teste rien. Vérifie le nom de la fonction, la logique, quelque chose cloche.
2. GREEN : écris le minimum pour passer
Ton seul objectif à cette étape : faire passer le test au vert. Le code peut être moche. Il peut même être « triché » : retourner une valeur en dur si un seul test l'attend. Ce n'est pas de la paresse : c'est de la discipline. Tu n'écris que ce que le test exige.
Le code « moche mais vert » est une étape, pas une destination. Tu n'es pas censé le livrer tel quel : l'étape REFACTOR est là pour ça. L'important, c'est d'aller vite au vert pour valider que le test est bon avant de s'en occuper.
3. REFACTOR : nettoie sans changer le comportement
Maintenant que les tests sont verts, tu peux nettoyer. Rename, extract, simplify, tout ce que tu veux, du moment que les tests restent verts après chaque changement. Les tests sont ton filet : ils te disent immédiatement si ton nettoyage a cassé quelque chose.
C'est l'étape REFACTOR qui rend le TDD payant. Sans filet de tests, nettoyer le code est risqué : on n'ose pas trop. Avec les tests verts qui restent verts, tu peux restructurer en confiance. C'est là que la qualité s'accumule, tour après tour.
À toi : mini TDD sur un palindrome
On va faire un tour complet de boucle. Tu as une fonction vide et deux tests rouges. Ton objectif : écrire le minimum pour le vert. Le refactor reste facultatif, mais on t'y invite.
On est à l'étape GREEN : la fonction estPalindrome est vide. Dans l'esprit TDD, écris (mentalement) le MINIMUM pour faire passer le test "radar". Quel est le risque si tu écris juste return true; ? Pense-y avant de dérouler.
Voir la réponse
return true; ferait passer le test « radar est un palindrome ». Mais le test « chat n'est pas un palindrome » passerait aussitôt au rouge (true n'est pas false). C'est exactement le rôle du second test : empêcher cette triche. Le minimum honnête ici n'est pas une valeur figée, mais la vraie comparaison : mot === mot.split('').reverse().join(''). Un seul test laisse la porte ouverte à la triche ; deux tests bien choisis la ferment.
Bloqué ? Voir le fix
Remplace le commentaire par return mot === mot.split('').reverse().join('');. La fonction inverse la chaîne (split('') découpe en lettres, reverse() retourne, join('') recolle) et compare. Relance : les deux tests passent au vert. Tu pourrais maintenant refactorer : extraire la logique d'inversion dans une variable nommée, rendre le code encore plus lisible. Les tests verts te protègent pendant ce nettoyage.
Faut-il TOUT faire en TDD ?
En 2014, David Heinemeier Hansson (DHH, créateur de Rails) a mis le feu aux poudres avec un article intitulé « TDD is dead. Long live testing. » Kent Beck et Martin Fowler ont répondu, et les trois ont tenu une série de discussions publiques enregistrées : martinfowler.com/articles/is-tdd-dead/.
Ce qui est frappant, a posteriori, c'est le consensus qui s'est dégagé, pas la guerre qu'on imagine :
- Ce qui est non négociable pour tous les trois : avoir du self-testing code, c'est-à-dire des tests automatisés qui tournent et vérifient le comportement. Ça, personne ne le remet en question, pas même DHH.
- Ce qui est un style, pas une morale : écrire le test avant le code. Le TDD au sens strict brille sur la logique bien spécifiée (comme ton palindrome). Il est moins naturel sur l'exploration, le prototypage, ou les interfaces utilisateur où la « spec » change à chaque essai.
- Le vrai problème pointé : le sur-mock. L'abus de mocks (des faux objets qu'on substitue aux vrais) rend les tests fragiles et découplés de la réalité. On en parle en détail à la leçon 7.
Vends les tests, pas le dogme. La question n'est pas « fais-tu du TDD ? » mais « as-tu des tests automatisés qui vérifient le comportement de ton code ? » Écrire-avant est un outil puissant dans certains contextes (la logique pure, le travail avec l'IA, un algorithme) et moins adapté dans d'autres. L'essentiel, c'est le filet, pas l'ordre dans lequel tu le tisses.
Avec l'IA, le TDD reprend du sens. Le flow naturel devient : tu écris le test (la spec de ce que tu veux), tu le donnes à l'IA, elle propose le code, et le test tranche immédiatement, vert ou rouge, sans interprétation. L'IA génère vite ; le test vérifie vite. Boucle de feedback ultra-courte.
You wrote a red test. Now what?
In lesson 5, you learned to write the test first, before the function even exists. You ended up with a red. That's intentional. But the real question is: what do you do next? And above all, in what order?
TDD (Test-Driven Development) answers in three steps. Three stages, in this precise order, in a loop. That's it. No magic, no ceremony: a rhythm. And this rhythm gives you the shortest feedback loop in software development. Between writing something and knowing whether it's right, only a few seconds go by.
The TDD loop: RED (write a failing test) → GREEN (write the minimum code to pass it) → REFACTOR (clean the code, tests stay green). Then repeat.
Each loop can take a few minutes. You validate continuously. You never wonder "does it still work?" — the tests tell you instantly, every iteration.
The three steps, rule by rule
1 — RED: write a failing test
Before writing a single line of production code, you write the test that describes the desired behaviour. That behaviour doesn't exist yet — so the test goes red. That's normal, that's the goal. A red test that describes something real is your starting point.
Strict RED rule: don't move to the next step until the test is truly red for the right reason. If you run it and it immediately goes green (without writing anything), the test is testing nothing. Check the function name, the logic — something is off.
2 — GREEN: write the minimum to pass
Your only goal at this stage: make the test go green. The code can be ugly. It can even be "cheated" — return a hardcoded value if only one test expects it. That's not laziness: it's discipline. You write only what the test demands.
"ugly but green" code is a step, not a destination. You're not expected to ship it as-is — the REFACTOR step is there for that. The important thing is to reach green quickly so you can confirm the test is sound before cleaning up.
3 — REFACTOR: clean without changing behaviour
Now that the tests are green, you can clean up. Rename, extract, simplify — whatever you like, as long as the tests stay green after each change. The tests are your safety net: they tell you immediately if your cleanup broke something.
The REFACTOR step is what makes TDD pay off. Without a test net, cleaning code is risky — you hesitate to touch things. With green tests staying green, you can restructure with confidence. That's where quality accumulates, loop after loop.
Your turn: mini TDD on a palindrome
Let's do one full loop. You have an empty function and two red tests. Your goal: write the minimum to go green. (Refactoring is optional — but we invite you to try.)
We're at the GREEN step: the isPalindrome function is empty. In the TDD spirit, write (mentally) the MINIMUM to pass the "radar" test. What's the risk if you just write return true;? Think it through before expanding.
Show the answer
return true; would pass the "'radar' is a palindrome" test — but the "'chat' is not a palindrome" test would immediately go red (true is not false). That's exactly the role of the second test: preventing that cheat. The honest minimum here isn't a hardcoded value but the real comparison: word === word.split('').reverse().join(''). One test leaves the door open to cheating; two well-chosen tests close it.
Stuck? Show the fix
Replace the comment with return word === word.split('').reverse().join('');. The function reverses the string (split('') cuts into letters, reverse() flips them, join('') glues them back) and compares. Rerun: both tests go green. Now you could refactor: extract the inversion logic into a named variable to make the code even more readable — the green tests protect you during that cleanup.
Should you do EVERYTHING in TDD?
In 2014, David Heinemeier Hansson (DHH, creator of Rails) sparked a firestorm with a post titled "TDD is dead. Long live testing." Kent Beck and Martin Fowler responded, and the three held a series of recorded public discussions: martinfowler.com/articles/is-tdd-dead/.
What's striking, in hindsight, is the consensus that emerged — not the war you'd imagine:
- What all three agree is non-negotiable: having self-testing code — automated tests that run and verify behaviour. Nobody disputes that, not even DHH.
- What is a style, not a moral stance: writing the test before the code. Strict TDD shines on well-specified logic (like your palindrome). It's less natural on exploration, prototyping, or UI where the "spec" changes with every attempt.
- The real problem identified: over-mocking. Abusing mocks (fake objects substituted for real ones) makes tests brittle and disconnected from reality. We cover this in detail in lesson 7.
Sell the tests, not the dogma. The question isn't "do you do TDD?" but "do you have automated tests that verify your code's behaviour?" Writing-first is a powerful tool in some contexts — pure logic, working with AI, algorithms — and less suited in others. What matters is the net, not the order in which you weave it.
With AI, TDD makes a comeback. The natural flow becomes: you write the test (the spec for what you want), hand it to the AI, it proposes the code, and the test decides immediately — green or red, no interpretation needed. The AI generates fast; the test verifies fast. Ultra-short feedback loop.
🎯 Pratique
S'entraîner (clique pour ouvrir) :
💬 Ré-explique sans regarder
Décris les 3 étapes du cycle TDD et la règle de chacune. (Indice : RED, GREEN, REFACTOR.)
🧠 Rappel libre
Sans remonter : à l'étape GREEN, pourquoi écrit-on le code MINIMUM, quitte à ce qu'il soit moche ?
⚖️ Juge le code de l'IA
Tu demandes du code. L'IA le pond, PUIS écrit les tests après coup, tout vert, et dit : « Voilà, c'est du TDD. » Tu acceptes, ou tu rejettes ?
The TDD cycle protects you during refactoring — but what about code that depends on other components? Network calls, databases, external services. In lesson 7: mocks and stubs, the art of isolating what you test, and the golden rule 'mock as little as possible'.
Lesson 7: Mocks and stubs →