L’IA n’a pas tué les tests, elle les rend indispensables
L’IA n’a pas tué les tests, elle les rend indispensables
Article 1 de la série “De la spécification à l’exécution — un workflow pour fiabiliser le code à l’ère IA”.
On pourrait penser qu’avec Claude, Cursor ou Copilot capables de générer une grande partie du code, les tests seraient devenus secondaires. L’idée est intuitive : si la machine produit du code en quelques secondes, autant la laisser faire. Pourtant, Kent Beck, l’un des auteurs de référence du TDD, explique en 2025 dans Augmented Coding: Beyond the Vibes qu’il pratique davantage de TDD avec un agent IA qu’auparavant. Le constat mérite qu’on s’y arrête.
Cet article ouvre une série de sept. Il présente le contexte : pourquoi les tests reprennent de l’importance au moment où l’IA semblait pouvoir les reléguer au second plan, et quel workflow se dessine pour produire du code fiable avec un agent. Les six articles suivants détaillent ce workflow étape par étape, de la spécification à l’exécution.
Définition rapide — Le TDD (Test-Driven Development) consiste à écrire d’abord un test qui échoue, puis le code qui le fait passer. Le cycle est court : Red, Green, Refactor. Cette pratique oblige à formaliser le comportement attendu avant d’écrire l’implémentation.
L’inversion économique
Pour comprendre ce qui a changé, il faut regarder où se situait le coût avant l’IA, et où il se situe désormais.
Avant l’IA, écrire un test demandait du temps. Pas énormément, mais assez pour que, dans une équipe sous pression, les tests soient souvent repoussés ou abandonnés. On en écrivait peu, et l’on en payait le prix plus tard sous forme de bugs en production. C’est ce qui a nourri, pendant des années, les critiques récurrentes contre le TDD : coût jugé trop élevé, manque de temps, priorité donnée à la livraison.
Avec l’IA, générer cinquante tests prend quelques secondes. Le coût de rédaction a fortement diminué, mais le travail s’est déplacé : il consiste maintenant à évaluer si un test a réellement de la valeur. Autrement dit, le coût principal n’est plus l’écriture, mais l’appréciation de la qualité. C’est ce coût-là qui a augmenté.
Avant l'IA Avec l'IA
───────── ────────
Coût d'écrire un test Coût d'écrire un test
■■■■■■■■■■ ▏
Coût de juger sa qualité Coût de juger sa qualité
■■■ ■■■■■■■■■■■■■
Birgitta Böckeler, chez ThoughtWorks, résume bien le problème en disant que la GenAI amplifie sans discernement. Autrement dit, l’IA ne sait pas distinguer automatiquement une bonne base de code d’une mauvaise. Sur un code médiocre, elle reproduit les défauts existants. Sur des tests faibles, elle en génère d’autres du même type, mais en plus grand nombre.
Le point clé n’est donc plus l’écriture du test, mais la spécification en amont et l’évaluation des tests produits. Ce sont toujours des activités humaines, et c’est à ce niveau que se joue désormais la fiabilité du code.
Trois pathologies documentées
Si vous laissez un agent IA écrire ses propres tests sans cadre, trois dérives reviennent de manière récurrente.
Pathologie 1 — La suppression silencieuse de tests
Kent Beck l’a décrit dans son interview au podcast Pragmatic Engineer (2025) : face à un test rouge, l’agent IA peut modifier ou supprimer le test plutôt que corriger le code de production. C’est souvent la solution la plus simple pour lui, puisque cela permet de faire passer le test rapidement.
Le problème est plus profond qu’une simple tricherie. Le test formalise le comportement attendu. Si l’agent le modifie pour faire passer le code, il ne corrige pas seulement un écart : il altère le contrat posé au départ. Et comme l’agent travaille souvent de façon autonome, cette dérive peut passer inaperçue jusqu’à la revue de code suivante.
Pathologie 2 — L’over-mocking systématique
Une étude empirique de 2025, Are Coding Agents Generating Over-Mocked Tests?, montre que les agents ont tendance à utiliser les mocks par défaut. C’est une stratégie commode : elle évite de préparer une fixture, d’instancier un objet réel ou de gérer un cas concret. Le test passe, et la couverture augmente. En apparence, tout fonctionne.
En réalité, le test ne vérifie plus grand-chose. Il contrôle surtout qu’un mock a bien été appelé. James Shore appelait cela le test theatre : une forme de test qui rassure, mais qui protège mal. Les défauts qui apparaissent dans l’interaction entre composants, pourtant fréquents, restent alors invisibles.
Pathologie 3 — Les tests “perpetually green”
Le cas le plus extrême est celui du test qui reste vert quelles que soient les modifications apportées au code de production. Cela peut venir d’assertions absentes, de mocks trop détachés de leur rôle, ou d’oracles tautologiques — autrement dit, des tests qui ne font que redire ce que le code fait déjà, au lieu de vérifier ce qu’il devrait faire.
Le Technology Radar v33 de ThoughtWorks (2025) met en avant le mutation testing pour détecter ce type de test. L’idée est simple : si l’on modifie volontairement le code de production, un test solide doit échouer. Si le test continue à passer, c’est probablement qu’il ne teste pas grand-chose. Le taux de mutants qui survivent devient alors un indicateur utile de la qualité réelle de la suite.
Une quatrième dérive, plus discrète, mérite d’être mentionnée : l’oracle from code. L’agent s’appuie sur l’implémentation pour déduire ce que le test doit attendre. Le test devient alors circulaire : il vérifie que le code fait ce que le code fait, sans référence explicite au comportement attendu.
Le workflow qui en résulte
Face à ces dérives, deux options existent : renoncer à l’IA, en se privant de la productivité qu’elle peut apporter, ou lui laisser une autonomie complète, avec le risque de produire le code fragile décrit précédemment. Une troisième voie s’est dessinée en 2024-2025, par convergence de Kent Beck, Martin Fowler et ThoughtWorks : encadrer l’IA dans un workflow où les tests ne sont plus produits par l’agent mais servent de contrainte à son travail.
1. SPÉCIFICATION l'humain formalise l'intention
(Gherkin, exemples, propriétés, types)
↓
2. TESTS l'humain écrit (ou valide strictement) les tests
AVANT toute écriture de code de production
↓
3. EXÉCUTION IA l'agent implémente sous la contrainte des tests
un cycle = un test = un commit
↓
4. VÉRIFICATION multi-agent (writer + critic) + outils déterministes
(mutation testing, lint, coverage)
↓
5. AUDIT bouclage : qualité des tests vérifiée régulièrement
(mensuel ou trimestriel selon criticité)
Le principe est le suivant : : les tests servent de spécification exécutable que l’IA doit respecter. Sans tests en amont, l’IA produit des implémentations plausibles, mais les erreurs deviennent plus difficiles à repérer. Avec des tests en amont, l’IA propose une solution, les tests la valident ou la rejettent, et le cycle reste sous contrôle humain.
Cette approche est étayée par plusieurs travaux publiés en 2025. Martin Fowler la décrit dans Exploring Gen AI: Spec-Driven Development. Une étude industrielle de la même année sur la génération de tests d’acceptance avec des LLMs rapporte également des résultats encourageants : scénarios Gherkin acceptés dans la grande majorité des cas, tests souvent corrects dès la première génération, et amélioration nette après correction ou ajout de contexte. Le travail restant repose alors sur l’humain, principalement pour valider la spécification. Acceptance Test Generation with Large Language Models.
Le plan des six articles suivants
Cette série présente le workflow étape par étape. Chaque article est autonome, mais l’ensemble reconstitue la séquence opérationnelle.
Article 2 — La spécification exécutable : Gherkin, exemples, propriétés. Comment formaliser une intention pour qu’un humain et un agent puissent partir d’une base commune. Niveaux de formalisation, pièges courants, et enseignements d’une étude industrielle de 2025 sur ce que produit l’IA à partir d’un Gherkin précis.
Article 3 — Qui écrit le test, qui écrit le code ? La répartition entre l’humain, l’agent IA et les outils déterministes (oui, il en existe — et la hype IA les a injustement éclipsés). Le pattern multi-agent writer + verifier qui émerge dans la recherche académique récente.
Article 4 — Mesurer si les tests valent quelque chose. Les quatre axes complémentaires : couverture (et ses pièges), mutation testing, test smells et robustesse. Un audit léger applicable à un projet existant.
Article 5 — Property-based testing : la défense contre les oracles faibles. Pourquoi les tests par exemples ratent souvent les cas limites, et pourquoi le property-based testing se prête bien à un usage assisté par IA. Avec un exemple sur un parseur SIP.
Article 6 — Mise en pratique : React + Go (Gin / GORM / PostgreSQL). Application du workflow à une pile moderne. Choix des outils par couche, intérêt de testcontainers-go face à sqlmock, et usage de Pact pour limiter les tests end-to-end.
Article 7 — Lancer l’exécution : du plan aux PR. Utilisation d’un plan.md persistant, les hooks pre-commit comme garde-fous, le pipeline CI multi-niveaux, et comment auditer un projet existant pour mettre en place ce workflow.
Le matériel d’accompagnement de la série (démos, skill TDD étendu pour Claude Code, exemples Pact) sera publié dans un dépôt public, avec le lien dans l’article suivant.
Trois points, qui forment le socle pour la suite.
Un. L’IA n’a pas supprimé le besoin de tests. Elle a surtout déplacé l’effort : écrire un test coûte peu, mais évaluer sa qualité demande davantage de travail qu’avant. Sans tests en amont, l’usage d’un agent IA augmente le risque de dette technique invisible.
Deux. Trois dérives reviennent dans les suites de tests produites en autonomie par un agent : suppression silencieuse de tests, over-mocking systématique et tests perpetually green. Elles sont documentées et mesurables.
Trois. Un workflow en cinq étapes — spécification, tests, exécution IA, vérification, audit — permet de combiner productivité et contrôle. Il ne s’agit pas d’écarter l’IA, mais de l’encadrer.
La semaine prochaine, nous commencerons par la spécification : comment formaliser une intention de façon à ce qu’un humain et un agent puissent s’appuyer sur la même base, sans ambiguïté.
Pour aller plus loin
- Kent Beck, Augmented Coding: Beyond the Vibes (2025) — signals.aktagon.com
- Kent Beck (entretien) sur le podcast The Pragmatic Engineer (2025) — newsletter.pragmaticengineer.com
- Martin Fowler, Exploring Gen AI: Spec-Driven Development (2025) — martinfowler.com
- Are Coding Agents Generating Over-Mocked Tests? An Empirical Study (arxiv 2602.00409, 2025) — arxiv.org
- Rethinking the Value of Agent-Generated Tests for LLM-Based Software Engineering Agents (arxiv 2602.07900, 2025) — arxiv.org
- Acceptance Test Generation with LLMs: An Industrial Case Study (arxiv 2504.07244, 2025) — arxiv.org
- ThoughtWorks Technology Radar volume 33 (2025) — thoughtworks.com
Cet article est le premier d’une série de 7 articles. Si le sujet vous intéresse, abonnez-vous au flux RSS du blog pour ne pas manquer la suite.