Skill Bench, del 2: Claude TDD-färdighet vs ingen färdighet

Del 1 av denna serie ställde en färdighet mot en tom prompt för en ställningsbyggnadsuppgift och fick en ojämn vinst. Del 2 gör det inte. Vi byggde samma Telegram-bot två gånger med Claude Sonnet, gav en körning den högst rankade test-driven-development-färdigheten i vår katalog, och färdigheten lade till tokens utan att lägga till ett test som spelade roll. Vi publicerar resultatet som det är, eftersom ett benchmark du bara publicerar när färdigheten vinner inte är ett benchmark.

Installation och metodik

Detta är N=1. En uppgift, en modell, en färdighet, körd en gång per arm. Det är inte tillräckligt med data för att hävda en procentuell skillnad i kvalitet, och vi kommer inte att låtsas något annat. Vad det räcker till är att visa vad som faktiskt händer i en enskild session, rad för rad, vilket är något som de flesta färdighetsmarknadsföring aldrig visar dig alls.

Uppgiften: bygg en Telegram todo-bot på aiogram v3 med fyra kommandon, /add, /list, /done, /delete, med in-memory lagring per användare. Briefen bad om en ren uppdelning: storage.py som innehåller ren logik utan Telegram-importer, bot.py som kopplar den logiken till aiogram-hanterare, och test_storage.py som täcker lagringsskiktet. Kör pytest tills det är grönt, stoppa sedan.

Båda armarna fick identisk prompt, identisk modell (Claude Sonnet) och identisk repo-ställning att utgå ifrån. Den enda variabeln: färdighetsarmen hade obra/superpowers' test-driven-development SKILL.md installerad, samma färdighet som fick 9.6 av 10 i vår katalog för att upprätthålla en strikt röd-grön-refaktor-loop och vägra låta en session markera arbete som klart medan ett test misslyckas. Baslinjearmen hade inget installerat utöver standardbeteendet för Claude Code. Fullständig metod för hur vi skriptar och loggar dessa körningar finns i hur vi testar Claude-färdigheter, och den bredare poängsättningsrubriken finns på vår metodiksida.

Vad båda armarna levererade

Båda armarna slutfördes. Båda uppnådde en helt grön pytest-körning. Båda producerade den uppdelning i tre filer som briefen bad om, med lagringslogik isolerad från aiogram-hanterarkoden. På ytan ser detta ut som oavgjort, och om du slutade läsa vid "båda blev gröna", skulle du dra slutsatsen att färdigheten inte gjorde någon skillnad och gå vidare.

Ingen av bot.py-filerna gjorde något överraskande. Var och en kopplade de fyra kommandona till aiograms Router- och Message-hanterare, parsade todo-texten eller indexet från kommandoargumenten och anropade direkt lagringsskiktet för det faktiska arbetet. Det var precis vad briefen bad om: håll bot-filen tunn, håll logiken testbar. När det gäller aiogram-kopplingen konvergerade de två sessionerna nästan helt, vilket i sig är en användbar datapunkt. Där de divergerade var helt på lagringssidan, i vad var och en ansåg vara värt ett test.

Skillnaden visar sig i vad varje arm bestämde var värt att testa, och i vad det kostade att komma dit.

Siffrorna

	Baslinje (ingen färdighet)	Färdighet (test-driven-development)	Delta
Totalt antal tokens	48,536	52,480	+8%
Skrivna tester	23	13	-10
Tester för undantagsfall	9	5	-4
Slutlig pytest-status	Grön	Grön	Oavgjort

Färdighetsarmen använde fler tokens för att producera en mindre testsvit med mindre undantagstäckning. Det är hela resultatet. Ingen dold asterisk, inget "men om du tittar på kodkvalitet istället för antal tester." Baslinjesessionen, som kördes utan någon process-ställning alls, skrev nästan dubbelt så många undantagsfall.

Att läsa testsviterna: 23 vs 13

Antal tester ensamt är en svag signal, så vi läste båda sviterna rad för rad istället för att lita på rubriknumret.

Baslinjens 23 tester täckte de fyra kommandona på "happy-path"-nivå, och fortsatte sedan in i gränsfall som ingen bad om vid namn: vad som händer när du markerar ett index utanför intervallet som klart, vad ett noll- eller negativt index gör, om en användares todo-lista läcker in i en annan användares, och om radering av objekt 2 korrekt flyttar indexen för objekt 3 och 4 så att /done 3 fortfarande pekar på rätt uppgift efteråt. Det sista är den typ av bugg som överlever en demo och sedan går sönder framför en riktig användare första gången de tar bort något från mitten av en lista. Nio av de 23 testerna fanns enbart för att undersöka dessa undantagsfall.

Färdighetsarmens 13 tester täckte samma fyra kommandon på "happy-path"-nivå, plus fem undantagsfall: mestadels index utanför intervallet och ett scenario med dubbel tillägg. Vad som saknas jämfört med baslinjen: inget explicit test för isolering per användare, och inget test som bekräftar indexbeteende efter att en borttagning flyttar listan. Lagringslogiken i färdighetsarmens storage.py kan mycket väl hantera dessa fall korrekt. Otestat korrekt beteende och testat korrekt beteende är dock inte samma påstående, och hela poängen med en testsvit är att täppa till den luckan.

Ingen av sviterna är dålig. Tretton tester med fem undantagsfall på en bot med fyra kommandon är en försvarbar utgångspunkt enligt alla normala ingenjörsstandarder. Jämförelsen ser bara fördömande ut bredvid en baslinje som, utifrån en identisk prompt utan någon röd-grön-ställning alls, skrev fler tester, inte färre.

Varför detta inte motbevisar TDD

Här är vad ett engångs-benchmark strukturellt inte kan se: TDD:s argument var aldrig "du kommer att skriva fler tester på ditt första försök." Det handlar om vad som händer under veckor av iteration, över den tionde funktionen som läggs till en kodbas som modellen inte skrev från grunden, vid den punkt där en trött ingenjör (eller en agent under tidspress) frestas att leverera med ett rött test och fixa det "senare."

Det är ett påstående om disciplin, inte ett påstående om engångsresultat, och detta benchmark kördes exakt en gång. Vi kan inte mäta disciplin i en enda session eftersom disciplin är det som hindrar dig från att gena i session sex, och det finns ingen session sex här.

Vi har dock ett spår av hur den disciplinen ser ut i praktiken, från våra egna testanteckningar på den test-driven-development skill page: under en session med tre funktioner vägrade färdigheten att hoppa över röd-grön-cykeln även när fixen verkade uppenbar och frestelsen att hoppa direkt till grönt fanns där. Den skrev det misslyckade testet först, såg det misslyckas av rätt anledning, och skrev sedan den minimala koden för att klara det, varje gång, över alla tre funktionerna. Ingen behövde ingripa och säga "vänta, skriv testet först." Det är det beteende en disciplinfärdighet förväntas ge, och det är inte samma beteende som "skriver fler tester i ett försök på en liten, välavgränsad modul."

På en uppgift av denna storlek och så väl specificerad var Claude Sonnets baslinjebedömning om vad som skulle testas redan solid. Färdigheten lade till en explicit process ovanpå en bedömning som ännu inte behövde mycket korrigering, och den processen kostade 8% fler tokens utan en motsvarande kvalitetsvinst vid detta specifika försök. Båda sakerna kan vara sanna: TDD är värt att ha installerat, och det hjälpte inte här.

Det finns också en enklare förklaring värd att nämna: att skriva ett misslyckat test, se det misslyckas, och sedan skriva den minimala koden för att klara det, tar mer fram och tillbaka än att skriva implementeringen och ett test för den i ett svep. Denna omkostnad är poängen med disciplinen när implementeringen är icke-trivial eller modellen är benägen att hoppa framåt. På en todo-bot med fyra kommandon var implementeringen aldrig i tvivel, så omkostnaden köpte process utan att köpa en kontroll av något som faktiskt riskerade att gå fel.

Vad detta betyder om du köper färdigheter

Den obekväma delen för oss, specifikt, är att vi säljer testade färdigheter, och vår egen testbänk visade just att en högt rankad färdighet inte vann en engångsjämförelse mot ingen färdighet alls. Vi föredrar att du ser det snarare än en höjdpunktssammanställning.

Den praktiska slutsatsen är att matcha färdigheten med uppgiften, inte med poängen. En katalogpoäng på 9.6/10 betyder att färdigheten gör vad den säger på ett tillförlitligt sätt och inte förstör din installation, inte att den vinner varje benchmark på varje uppgiftsstorlek. Om din uppgift är en liten, väl specificerad modul som du bygger från grunden, i ett svep, kan en stark modells standardbedömning redan täcka de undantagsfall du bryr dig om, och en processfärdighet är en omkostnad du betalar för utan en motsvarande fördel under den sessionen. Om din uppgift är en kodbas du kommer att arbeta med i månader, med flera bidragsgivare och långa perioder mellan sessioner där genvägar tyst ackumuleras, är det vad en disciplinfärdighet som TDD är byggd för att förhindra, och ett engångs-benchmark skulle aldrig fånga det värdet från början.

Hastighetsfärdigheter och disciplinfärdigheter svarar på olika frågor. Läs en färdighets beskrivning för vilken fråga den svarar på innan du installerar den för fel uppgift. Vi täcker hur man läser den signalen i vår sammanställning av de bästa kodningsfärdigheterna.

Reproducera det själv

Uppgiften är tillräckligt liten för att köras om på en eftermiddag. Klona ett rent aiogram v3-projekt, kör sedan samma prompt två gånger: en gång i en ren Claude Code-session, en gång med obra/superpowers' test-driven-development-färdighet installerad. Be om /add /list /done /delete med in-memory lagring per användare, en storage.py/bot.py-uppdelning, och en pytest-svit som körs grön innan du anser det klart. Logga totalt antal tokens från varje sessions användningssammanfattning, jämför sedan de två test_storage.py-filerna manuellt: räkna påståenden, och flagga specifikt allt som rör negativa index, saknade nycklar, isolering per användare, och indexförskjutningar efter en borttagning. Dessa fyra kategorier är där vi såg gapet, och de är de som är värda att kontrollera på vilken todo-liknande CRUD-app som helst, oavsett vilken färdighet du testar.

FAQ

Betyder detta att TDD-färdigheten är dålig?

Nej. Det betyder att ett engångs-benchmark på en liten, väl specificerad modul inte är det test som visar vad TDD är till för. Färdighetens värde ligger i att förhindra genvägar under en lång session eller ett långt projekt, vilket detta benchmark, avsiktligt, inte kördes tillräckligt länge för att mäta.

Varför skrev färdighetsarmen färre tester om den upprätthåller en striktare process?

Röd-grön-refaktor-loopen driver dig att skriva ett test för det beteende du ska implementera, sedan implementera det, och sedan gå vidare till nästa beteende. Den uppmanar dig inte automatiskt att gå tillbaka och lägga till tester för gränsfall som ingen uttryckligen bad om, om inte sessionen tar tid att brainstorma dem separat. Baslinjearmen, obegränsad av en fast cykel, spenderade tydligen mer av sin output på just den brainstormingen.

Ska jag installera en TDD-färdighet för Claude Code?

Om du arbetar i en kodbas som du kommer att återvända till upprepade gånger, särskilt med andra bidragsgivare eller långa uppehåll mellan sessioner, ja. Det är en försäkring mot ett specifikt fel: att tyst leverera med ett rött test eftersom fixen verkade uppenbar. Det felet visar sig inte i ett enda eftermiddags-benchmark, men det visar sig i verkliga projekt.

Vad kommer härnäst i denna serie?

Del 3 av "The Skill Bench" tittar på en felsökningsfärdighet mot en omodifierad buggjakt i ett snake-spel. Del 4 granskar ett Google zx-automationsskript. Båda följer samma regel som denna: samma uppgift, samma modell, en variabel, siffror publiceras oavsett.

Skill Bench-serien

Del 2 av 4. Läs del 1: landningssidesbygge, del 3: felsökning av snake, och del 4: granskning av ett Google zx-skript.