Le Banc d'Essai, partie 2 : Compétence TDD de Claude vs. sans

La partie 1 de cette série a opposé une compétence à une invite vierge sur une tâche d'échafaudage et a obtenu une victoire écrasante. La partie 2 ne le fait pas. Nous avons construit le même bot Telegram deux fois avec Claude Sonnet, avons donné à une exécution la compétence de développement piloté par les tests la mieux notée de notre catalogue, et la compétence a ajouté des tokens sans ajouter de test pertinent. Nous publions ce résultat tel quel, car un benchmark que vous ne publiez que lorsque la compétence gagne n'est pas un benchmark.

Configuration et méthodologie

C'est N=1. Une tâche, un modèle, une compétence, exécutée une fois par branche. Ce n'est pas assez de données pour revendiquer une différence de qualité en pourcentage, et nous n'allons pas prétendre le contraire. Ce pour quoi c'est suffisant, c'est de montrer ce qui se passe réellement lors d'une seule session, ligne par ligne, ce que la plupart du marketing de compétences ne vous montre jamais.

La tâche : construire un bot Telegram de gestion de tâches sur aiogram v3 avec quatre commandes, /add, /list, /done, /delete, soutenu par un stockage en mémoire propre à chaque utilisateur. Le cahier des charges demandait une séparation claire : storage.py contenant la logique pure sans importations Telegram, bot.py reliant cette logique aux gestionnaires aiogram, et test_storage.py couvrant la couche de stockage. Exécuter pytest jusqu'à ce qu'il soit vert, puis arrêter.

Les deux branches ont reçu l'invite identique, le modèle identique (Claude Sonnet) et l'échafaudage de dépôt identique pour commencer. La seule variable : la branche avec compétence avait le fichier test-driven-development SKILL.md de obra/superpowers installé, la même compétence qui a obtenu 9.6 sur 10 dans notre catalogue pour avoir imposé une boucle stricte de red-green-refactor et refusé de laisser une session marquer le travail comme terminé tant qu'un test échoue. La branche de référence n'avait rien d'installé au-delà du comportement par défaut de Claude Code. La méthode complète pour la façon dont nous scriptons et enregistrons ces exécutions se trouve dans comment nous testons les compétences Claude, et la grille d'évaluation plus large se trouve sur notre page de méthodologie.

Ce que les deux branches ont livré

Les deux branches ont terminé. Les deux ont obtenu une exécution pytest entièrement verte. Les deux ont produit la séparation en trois fichiers demandée par le cahier des charges, avec la logique de stockage isolée du code du gestionnaire aiogram. En surface, cela ressemble à une égalité, et si vous arrêtiez de lire à « les deux sont devenus verts », vous concluriez que la compétence n'a fait aucune différence et passeriez à autre chose.

Aucun fichier bot.py n'a fait quoi que ce soit de surprenant. Chacun a connecté les quatre commandes aux gestionnaires Router et Message d'aiogram, a extrait le texte de la tâche ou l'index des arguments de commande, et a directement appelé la couche de stockage pour le travail réel. C'est exactement ce que le cahier des charges demandait : garder le fichier du bot léger, garder la logique testable. Concernant le câblage aiogram, les deux sessions ont convergé presque complètement, ce qui est en soi un point de données utile. Là où elles ont divergé, c'était entièrement du côté du stockage, dans ce que chacune considérait comme digne d'un test.

La différence apparaît dans ce que chaque branche a décidé de tester, et dans ce que cela a coûté pour y arriver.

Les chiffres

	Référence (sans compétence)	Compétence (test-driven-development)	Delta
Total tokens	48,536	52,480	+8%
Tests écrits	23	13	-10
Tests de chemins d'exception	9	5	-4
Statut final pytest	Vert	Vert	Égalité

La branche avec compétence a utilisé plus de tokens pour produire une suite de tests plus petite avec moins de couverture d'exceptions. C'est le résultat complet. Pas d'astérisque caché, pas de « mais si vous regardez la qualité du code au lieu du nombre de tests ». La session de référence, fonctionnant sans aucun échafaudage de processus, a écrit presque deux fois plus de cas de chemins d'exception.

Lecture des suites de tests : 23 contre 13

Le nombre de tests seul est un signal faible, nous avons donc lu les deux suites ligne par ligne au lieu de faire confiance au nombre d'en-tête.

Les 23 tests de la référence couvraient les quatre commandes au niveau du chemin nominal, puis ont continué avec des cas limites que personne n'avait demandés nommément : ce qui se passe lorsque vous marquez un index hors limites comme terminé, ce que fait un index zéro ou négatif, si la liste de tâches d'un utilisateur se propage à celle d'un autre utilisateur, et si la suppression de l'élément 2 décale correctement les indices des éléments 3 et 4 afin que /done 3 pointe toujours vers la bonne tâche par la suite. Ce dernier est le genre de bug qui survit à une démo et se manifeste ensuite devant un utilisateur réel la première fois qu'il supprime quelque chose du milieu d'une liste. Neuf des 23 tests existaient purement pour sonder ces chemins d'exception.

Les 13 tests de la branche avec compétence couvraient les mêmes quatre commandes au niveau du chemin nominal, plus cinq cas de chemins d'exception : principalement des indices hors limites et un scénario d'ajout en double. Ce qui manque par rapport à la référence : aucun test explicite d'isolation par utilisateur, et aucun test confirmant le comportement des indices après qu'une suppression décale la liste. La logique de stockage dans le fichier storage.py de la branche avec compétence peut très bien gérer ces cas correctement. Cependant, un comportement correct non testé et un comportement correct testé ne sont pas la même affirmation, et tout l'intérêt d'une suite de tests est de combler cet écart.

Aucune des suites n'est mauvaise. Treize tests avec cinq cas d'exception sur un bot à quatre commandes est un point de départ défendable selon toute norme d'ingénierie normale. La comparaison ne semble accablante que par rapport à une référence qui, partant d'une invite identique sans aucun échafaudage red-green, a écrit plus de tests, et non moins.

Pourquoi cela ne réfute pas le TDD

Voici ce qu'un benchmark ponctuel ne peut structurellement pas voir : l'argument du TDD n'a jamais été « vous écrirez plus de tests à votre première tentative ». Il s'agit de ce qui se passe au fil des semaines d'itération, à travers la dixième fonctionnalité ajoutée à une base de code que le modèle n'a pas écrite de zéro, au moment où un ingénieur fatigué (ou un agent sous pression) est tenté de livrer avec un test rouge et de le corriger « plus tard ».

C'est une affirmation de discipline, pas une affirmation de résultat ponctuel, et ce benchmark n'a exécuté qu'une seule tentative. Nous ne pouvons pas mesurer la discipline en une seule session car la discipline est ce qui vous empêche de prendre un raccourci à la sixième session, et il n'y a pas de sixième session ici.

Nous avons une trace de ce à quoi ressemble cette discipline en pratique, tirée de nos propres notes de test sur la page de compétence test-driven-development : au cours d'une session de trois fonctionnalités, la compétence a refusé de sauter le cycle rouge-vert même lorsque la correction semblait évidente et que la tentation de passer directement au vert était là. Elle a d'abord écrit le test échouant, l'a vu échouer pour la bonne raison, puis a écrit le code minimum pour le faire passer, à chaque fois, sur les trois fonctionnalités. Personne n'a eu à intervenir et à dire « attendez, écrivez le test d'abord ». C'est le comportement qu'une compétence de discipline est censée apporter, et ce n'est pas le même comportement que « écrit plus de tests en une seule tentative sur un petit module bien délimité ».

Sur une tâche de cette taille et aussi bien spécifiée, le jugement de base de Claude Sonnet sur ce qu'il fallait tester était déjà solide. La compétence a ajouté un processus explicite en plus d'un jugement qui n'avait pas encore besoin de beaucoup de correction, et ce processus a coûté 8% de tokens supplémentaires sans gain de qualité correspondant sur cette tentative particulière. Les deux choses peuvent être vraies : le TDD vaut la peine d'être installé, et il n'a pas aidé ici.

Il y a aussi une explication plus simple à mentionner : écrire un test échouant, le voir échouer, puis écrire le code minimum pour le faire passer demande plus d'allers-retours que d'écrire l'implémentation et un test pour celle-ci en une seule passe. Ce surcoût est le but de la discipline lorsque l'implémentation n'est pas triviale ou que le modèle est enclin à sauter des étapes. Sur un bot de tâches à quatre commandes, l'implémentation n'a jamais été mise en doute, donc le surcoût a apporté un processus sans apporter de vérification sur quoi que ce soit qui risquait réellement de mal tourner.

Ce que cela signifie si vous achetez des compétences

La partie inconfortable pour nous, spécifiquement, est que nous vendons des compétences testées, et notre propre banc d'essai vient de montrer qu'une compétence très bien notée ne gagne pas une comparaison ponctuelle contre aucune compétence du tout. Nous préférons que vous voyiez cela plutôt qu'un montage des meilleurs moments.

La leçon pratique est d'adapter la compétence au travail, et non au score. Un score de catalogue de 9.6/10 signifie que la compétence fait ce qu'elle dit de manière fiable et ne perturbe pas votre configuration, et non qu'elle gagne chaque benchmark sur chaque taille de tâche. Si votre travail est un petit module bien spécifié que vous construisez de zéro, en une seule fois, le jugement par défaut d'un modèle puissant peut déjà couvrir les chemins d'exception qui vous intéressent, et une compétence de processus est un surcoût que vous payez sans un avantage correspondant lors de cette session. Si votre travail est une base de code que vous toucherez pendant des mois, avec plusieurs contributeurs et de longues périodes entre les sessions où les raccourcis s'accumulent silencieusement, c'est ce qu'une compétence de discipline comme le TDD est conçue pour prévenir, et un benchmark d'une seule session n'allait de toute façon jamais capturer cette valeur.

Les compétences de vitesse et les compétences de discipline répondent à des questions différentes. Lisez la description d'une compétence pour savoir à quelle question elle répond avant de l'installer pour le mauvais travail. Nous expliquons comment interpréter ce signal dans notre tour d'horizon des meilleures compétences de codage.

Reproduisez-le vous-même

La tâche est suffisamment petite pour être réexécutée en un après-midi. Clonez un projet aiogram v3 nu, puis exécutez l'invite identique deux fois : une fois dans une session Claude Code propre, une fois avec la compétence test-driven-development de obra/superpowers installée. Demandez /add /list /done /delete avec un stockage en mémoire par utilisateur, une séparation storage.py/bot.py, et une suite pytest qui s'exécute en vert avant de considérer que c'est terminé. Enregistrez le total des tokens du résumé d'utilisation de chaque session, puis comparez manuellement les deux fichiers test_storage.py : comptez les assertions, et signalez spécifiquement tout ce qui concerne les indices négatifs, les clés manquantes, l'isolation par utilisateur et les décalages d'indices après une suppression. Ces quatre catégories sont là où nous avons constaté l'écart, et ce sont celles qui méritent d'être vérifiées sur toute application CRUD de type « todo » quelle que soit la compétence que vous testez.

FAQ

Cela signifie-t-il que la compétence TDD est mauvaise ?

Non. Cela signifie qu'un benchmark ponctuel sur un petit module bien spécifié n'est pas le test qui montre à quoi sert le TDD. La valeur de la compétence réside dans la prévention des raccourcis sur une longue session ou un long projet, ce que ce benchmark, de par sa conception, n'a pas duré assez longtemps pour mesurer.

Pourquoi la branche avec compétence a-t-elle écrit moins de tests si elle impose un processus plus strict ?

La boucle red-green-refactor vous pousse à écrire un test pour le comportement que vous êtes sur le point d'implémenter, puis à l'implémenter, puis à passer au comportement suivant. Elle ne vous incite pas automatiquement à revenir en arrière et à ajouter des tests pour des cas limites que personne n'a explicitement demandés, à moins que la session ne prenne le temps de les brainstormer séparément. La branche de référence, non contrainte par un cycle fixe, a apparemment consacré une plus grande partie de sa production à ce brainstorming.

Devrais-je installer une compétence TDD pour Claude Code ?

Si vous travaillez sur une base de code à laquelle vous reviendrez à plusieurs reprises, surtout avec d'autres contributeurs ou de longs intervalles entre les sessions, oui. C'est une assurance contre un mode de défaillance spécifique : livrer discrètement avec un test rouge parce que la correction semblait évidente. Ce mode de défaillance n'apparaît pas dans un benchmark d'un seul après-midi, mais il apparaît dans de vrais projets.

Quelle est la suite de cette série ?

La partie 3 du « Banc d'Essai des Compétences » examine une compétence de débogage face à une chasse aux bugs sur un jeu de snake non modifié. La partie 4 audite un script d'automatisation Google zx. Les deux suivent la même règle que celle-ci : même tâche, même modèle, une seule variable, chiffres imprimés dans tous les cas.

La série Le Banc d'Essai des Compétences

Partie 2 sur 4. Lisez partie 1 : construction de page de destination, partie 3 : débogage de snake, et partie 4 : audit d'un script Google zx.