200 tests… et la suite met 20 minutes à tourner
Tu rejoins un projet. Il y a 200 tests. C'est bien, non ? Tu lances la suite. Tu attends. Deux minutes. Cinq. Dix. Vingt. La moitié des tests s'écroule parce que l'environnement n'est pas parfaitement configuré, ou parce qu'un serveur distant est lent. Le CI devient vert ou rouge au hasard selon la météo réseau. L'équipe a arrêté de faire confiance aux tests. Elle les lance une fois par semaine, en croisant les doigts.
Le problème n'est pas qu'il y a trop de tests. C'est qu'ils sont tous du mauvais type : 200 tests end-to-end qui cliquent dans un navigateur, appellent une vraie base de données, et simulent un vrai utilisateur du début à la fin. Chacun est lent. Chacun peut casser pour une raison qui n'a rien à voir avec ton code.
La solution s'appelle la pyramide des tests. Ce n'est pas une règle rigide, c'est une boussole : la forme de ta suite dit quelque chose sur sa santé. Et cette leçon, c'est le moment de tout assembler : la pyramide, le code de l'IA, et le workflow pour ne plus se faire avoir.
Le symptôme d'une suite déséquilibrée : si tes tests sont lents, fragiles, ou si tu évites de les lancer parce qu'ils « cassent souvent pour rien », c'est presque toujours un problème de proportion. Trop de tests hauts dans la pyramide, pas assez en bas.
La pyramide des tests
Mike Cohn a proposé cette image en 2009, et Martin Fowler l'a popularisée : imagine une pyramide à trois étages. La largeur d'un étage représente le nombre de tests que tu dois y mettre. La hauteur représente la lenteur et le coût.
La base : les tests unitaires. Ils testent une seule fonction, isolée du reste (pas de base de données, pas de réseau, pas d'autre module). Ils s'exécutent en millisecondes. Tu peux en avoir des centaines, ils tournent en quelques secondes. C'est là que doit vivre l'essentiel de ta logique métier.
Le milieu : les tests d'intégration. Ils vérifient que plusieurs morceaux fonctionnent ensemble correctement : ton code + ta base de données, ton service + l'API tierce. Moins nombreux que les unitaires, un peu plus lents, mais ils attrapent des bugs que les unitaires ne voient pas.
Le sommet : les tests end-to-end. Ils simulent un vrai utilisateur dans un vrai navigateur, du clic jusqu'à la réponse serveur. Utiles pour valider les parcours critiques (connexion, paiement), mais Fowler les qualifie clairement de « brittle, expensive to write, and time consuming to run » : fragiles, coûteux à écrire, et lents à tourner. Source : martinfowler.com.
La nuance de Kent C. Dodds : sa « Testing Trophy » nuance la pyramide selon le contexte. Sa formule : « Write tests. Not too many. Mostly integration. » L'idée-clé reste la même : beaucoup de petits tests rapides à la base, peu de gros tests lents au sommet. La forme exacte dépend de ton projet. Source : kentcdodds.com.
À toi : attrape le bug de frontière de l'IA
L'IA a généré une fonction de remise « gros panier » : -10 % à partir de 100 €. Le code a l'air correct. Tu lances le test sur 150 €, il passe au vert. Tout va bien ? Pas tout à fait. Un bug de frontière se cache dans l'inégalité. C'est l'erreur la plus fréquente de l'IA sur les cas limites. Lance les tests : l'un va passer au rouge. Lis le message, corrige (deux caractères suffisent) et relance jusqu'au vert.
La spec dit « -10 % à partir de 100 € ». L'IA a écrit if (total > 100). Que renvoie remiseGrosPanier(100), et est-ce conforme à la spec ? Réfléchis avant de dérouler.
Voir la réponse
remiseGrosPanier(100) renvoie 100 (pas de remise), car 100 > 100 est faux. Or « à partir de 100 € » inclut 100 : la remise devrait s'appliquer et renvoyer 90. C'est un bug de frontière (off-by-one sur l'inégalité) : invisible sur le cas 150 €, attrapé seulement par un test du cas limite exact (100 €). Le fix : remplacer > par >=.
Bloqué sur la correction ? Voir le fix
Remplace > par >=. La ligne devient if (total >= 100). La spec dit « à partir de 100 € », donc 100 est inclus. Relance : les deux tests passent au vert. Tu viens d'attraper le bug de frontière le plus classique de l'IA. Le genre qui passe toujours inaperçu sur le cas heureux (150 €) et n'explose qu'au cas limite exact.
Pourquoi l'IA rate ce cas : Simon Willison le formule clairement (mars 2025) : les hallucinations « visibles » de l'IA (inventer une fonction inexistante) sont les moins dangereuses, elles plantent tout de suite. Les vraies bombes sont les bugs de logique : le code tourne, le résultat est faux sur un cas limite, et rien ne prévient. Source : simonwillison.net.
Le workflow complet pour tester le code de l'IA
C'est le capstone du cours. Tu sais maintenant écrire un test, le faire passer au rouge, corriger, et revenir au vert. Tu connais la pyramide. Tu as vu où l'IA se plante. Voici comment assembler tout ça en une méthode, à chaque fois que tu reçois du code généré.
Workflow en check-list, à appliquer à chaque code de l'IA :
- Demande le code ET les tests, mais lis les tests toi-même : ils disent noir sur blanc ce que le code est censé faire. Si les tests ne correspondent pas à ta spec, le code non plus.
- Vérifie qu'un test sait passer au rouge sans le code (ou avec un code intentionnellement cassé). Un test qui reste vert sans le code est un test fantôme : il ne prouve rien (cf. leçon 5).
- Ajoute les cas limites que l'IA a presque sûrement oubliés : la valeur frontière exacte (100 €, pas 150 €), le zéro, le vide, le négatif (cf. leçon 4).
- Méfie-toi des bugs de logique plus que des plantages visibles. Un nom de fonction inventé, tu le vois tout de suite. Une inégalité
>au lieu de>=, elle passe en silence pendant des semaines.
Avec ce workflow, l'IA devient un accélérateur sûr. Sans lui, c'est rouler sans phares : le code avance vite, mais les bugs de frontière s'accumulent en silence jusqu'en production. Les tests ne ralentissent pas le développement : ils déplacent la découverte du bug du pire moment (la prod) au meilleur (ton éditeur).
Règle d'or de fin de cours : coder avec l'IA sans tests, c'est rouler sans phares. Avec des tests, et le bon workflow, l'IA devient un accélérateur sur lequel tu peux compter.
200 tests… and the suite takes 20 minutes to run
You join a project. There are 200 tests. Sounds good, right? You run the suite. You wait. Two minutes. Five. Ten. Twenty. Half the tests collapse because the environment isn't perfectly set up, or because a remote server is slow. The CI turns green or red at random depending on network weather. The team stopped trusting the tests. They run them once a week, fingers crossed.
The problem isn't that there are too many tests. It's that they're all the wrong type: 200 end-to-end tests that click through a browser, call a real database, and simulate a real user from start to finish. Each one is slow. Each one can break for a reason that has nothing to do with your code.
The solution is called the test pyramid. It's not a rigid rule, it's a compass: the shape of your suite says something about its health. And this lesson is where we put it all together — the pyramid, the AI's code, and the workflow to stop being fooled.
Symptom of an unbalanced suite: if your tests are slow, flaky, or you avoid running them because they "often break for no reason" — that's almost always a proportion problem. Too many tests high up in the pyramid, not enough at the base.
The test pyramid
Mike Cohn coined this image in 2009, and Martin Fowler popularized it: picture a pyramid with three layers. The width of a layer represents how many tests you should have there. The height represents slowness and cost.
The base: unit tests. They test one single function, isolated from everything else (no database, no network, no other module). They run in milliseconds. You can have hundreds; they finish in seconds. This is where the bulk of your business logic should live.
The middle: integration tests. They verify that several pieces work correctly together: your code + your database, your service + the third-party API. Fewer than unit tests, a bit slower, but they catch bugs unit tests can't see.
The tip: end-to-end tests. They simulate a real user in a real browser, from click to server response. Useful to validate critical flows — login, payment — but Fowler is clear: they are "brittle, expensive to write, and time consuming to run". Source: martinfowler.com.
Kent C. Dodds' nuance: his "Testing Trophy" refines the pyramid per context. His formula: "Write tests. Not too many. Mostly integration." The core idea holds: lots of small fast tests at the base, few large slow tests at the top. The exact shape depends on your project. Source: kentcdodds.com.
Your turn: catch the AI's boundary bug
The AI generated a "big cart" discount function — -10% from 100 €. The code looks correct. You run the test at 150 €, it goes green. All good? Not quite. There's a boundary bug hiding in the inequality — exactly the most frequent mistake AI makes on edge cases. Run the tests: one will turn red. Read the message, fix it (two characters are enough) and rerun until green.
The spec says "-10% from 100 € up". The AI wrote if (total > 100). What does bigCartDiscount(100) return, and is it correct per the spec? Think before expanding.
Show the answer
bigCartDiscount(100) returns 100 (no discount), because 100 > 100 is false. But "from 100 € up" includes 100 — the discount should apply and return 90. This is a boundary bug (off-by-one on the inequality): invisible at 150 €, only caught by a test of the exact edge case (100 €). The fix: replace > with >=.
Stuck on the fix? Show it
Replace > with >=. The line becomes if (total >= 100). The spec says "from 100 € up", so 100 is included. Rerun: both tests go green. You just caught the most classic boundary bug AI produces — the kind that always slips past the happy-path test (150 €) and only surfaces at the exact edge case.
Why AI misses this: Simon Willison puts it clearly (March 2025) — the "visible" AI hallucinations (inventing a non-existent function) are the least dangerous, they crash immediately. The real bombs are logic bugs: the code runs, the result is wrong on an edge case, and nothing warns you. Source: simonwillison.net.
The full workflow to test AI-generated code
This is the course capstone. You can now write a test, make it go red, fix, and return to green. You know the pyramid. You've seen where AI slips up. Here's how to assemble it all into a method, every time you receive generated code.
Workflow checklist — apply to every piece of AI code:
- Ask for the code AND the tests, but read the tests yourself: they state in black and white what the code is supposed to do. If the tests don't match your spec, neither does the code.
- Verify that a test can go red without the code (or with intentionally broken code). A test that stays green without the code is a ghost test — it proves nothing (see lesson 5).
- Add the edge cases AI almost certainly missed: the exact boundary value (100 €, not 150 €), zero, empty, negative (see lesson 4).
- Watch for logic bugs more than visible crashes. A made-up function name, you see it straight away. An inequality
>instead of>=passes silently for weeks.
With this workflow, AI becomes a safe accelerator. Without it, you're driving with no headlights: the code moves fast, but boundary bugs accumulate silently until production. Tests don't slow development down — they move bug discovery from the worst moment (prod) to the best (your editor).
Golden rule to close the course: coding with AI and no tests is driving with no headlights. With tests — and the right workflow — AI becomes an accelerator you can rely on.
🎯 Pratique
S'entraîner (clique pour ouvrir) :
💬 Ré-explique sans regarder
Décris les 3 étages de la pyramide des tests et pourquoi il en faut beaucoup en bas et peu en haut.
🧠 Rappel libre
Sans remonter : cite les étapes pour tester du code généré par l'IA.
⚖️ Juge le code de l'IA
L'IA livre remiseGrosPanier + un seul test : expect(remiseGrosPanier(150)).toBe(135), tout vert, et dit : « C'est testé, ça marche. » Tu acceptes, ou tu rejettes ?
> au lieu de >=). Un test vert sur le happy path ne prouve rien sur les bords. Il faut exiger le test du cas limite : lui, il passe au rouge et révèle le bug.if (total > 100) pour « remise à partir de 100 € ». Quel test l'attrape ?You can now write tests that catch mistakes, yours and the AI's. The natural next step: the "Coding with AI" course, to weave this reflex into your whole way of working with an assistant.
Course: Coding with AI →