Ferdighetsbenken, del 2: Claude TDD-ferdighet vs ingen ferdighet

Del 1 av denne serien satte en ferdighet opp mot en tom prompt på en stillasoppgave og fikk en skjev seier. Del 2 gjør ikke det. Vi bygget den samme Telegram-boten to ganger med Claude Sonnet, ga den ene kjøringen den høyest rangerte test-driven-development-ferdigheten i vår katalog, og ferdigheten la til tokens uten å legge til en test som betydde noe. Vi publiserer dette resultatet som det er, fordi en benchmark du bare publiserer når ferdigheten vinner, ikke er en benchmark.

Oppsett og metodikk

Dette er N=1. Én oppgave, én modell, én ferdighet, kjørt én gang per arm. Det er ikke nok data til å hevde en prosentvis forskjell i kvalitet, og vi kommer ikke til å late som noe annet. Det er nok til å vise hva som faktisk skjer i en enkelt sesjon, linje for linje, noe de fleste ferdighetsmarkedsføringer aldri viser deg i det hele tatt.

Oppgaven: bygg en Telegram todo-bot på aiogram v3 med fire kommandoer, /add, /list, /done, /delete, støttet av minnebasert lagring avgrenset per bruker. Briefen ba om et rent skille: storage.py som inneholder ren logikk uten Telegram-importer, bot.py som kobler den logikken til aiogram-handlere, og test_storage.py som dekker lagringslaget. Kjør pytest til den er grønn, og stopp deretter.

Begge armene fikk den identiske prompten, den identiske modellen (Claude Sonnet), og det identiske repo-stillasen å starte fra. Den eneste variabelen: ferdighetsarmen hadde obra/superpowers' test-driven-development SKILL.md installert, den samme ferdigheten som scoret 9.6 av 10 i vår katalog for å håndheve en streng rød-grønn-refaktor-sløyfe og nekte å la en sesjon markere arbeid som ferdig mens en test feiler. Baseline-armen hadde ingenting installert utover standard Claude Code-oppførsel. Full metode for hvordan vi skriptet og logger disse kjøringene er i hvordan vi tester Claude-ferdigheter, og den bredere scoringsrubrikken finnes på vår metodikkside.

Hva begge armene leverte

Begge armene ble ferdige. Begge oppnådde en fullstendig grønn pytest-kjøring. Begge produserte den tredelte filstrukturen briefen ba om, med lagringslogikk isolert fra aiogram-handlerkoden. På overflaten ser dette ut som uavgjort, og hvis du sluttet å lese ved "begge ble grønne", ville du konkludert med at ferdigheten ikke gjorde noen forskjell og gått videre.

Ingen av bot.py-filene gjorde noe overraskende. Hver koblet de fire kommandoene til aiograms Router- og Message-handlere, parset todo-teksten eller indeksen ut av kommandoargumentene, og kalte direkte inn i lagringslaget for det faktiske arbeidet. Det er nøyaktig hva briefen ba om: hold bot-filen tynn, hold logikken testbar. Når det gjelder aiogram-koblingen, konvergerte de to sesjonene nesten fullstendig, noe som i seg selv er et nyttig datapunkt. Der de divergerte var utelukkende på lagringssiden, i hva hver anså som verdt en test.

Forskjellen viser seg i hva hver arm bestemte var verdt å teste, og hva det kostet å komme dit.

Tallene

| | |---|---| | Totalt antall tokens | 48,536 | | Antall skrevne tester | 23 | | Tester for unntaksveier | 9 | | Endelig pytest-status | Grønn |

Ferdighetsarmen brukte flere tokens for å produsere en mindre testpakke med mindre unntaksdekning. Det er hele resultatet. Ingen skjult stjerne, ingen "men hvis du ser på kodekvalitet i stedet for antall tester". Baseline-sesjonen, som kjørte uten prosess-stillas i det hele tatt, skrev nesten dobbelt så mange unntaksvei-tilfeller.

Lesing av testpakkene: 23 vs 13

Antall tester alene er et svakt signal, så vi leste begge pakkene linje for linje i stedet for å stole på overskriftstallet.

Baselinens 23 tester dekket de fire kommandoene på happy-path-nivå, og fortsatte deretter inn i grensetilfeller ingen ba om ved navn: hva som skjer når du markerer en indeks utenfor rekkevidde som ferdig, hva en null eller negativ indeks gjør, om én brukers todo-liste lekker inn i en annen brukers, og om sletting av element 2 korrekt forskyver indeksene til element 3 og 4 slik at /done 3 fortsatt peker på riktig oppgave etterpå. Den siste er den typen feil som overlever en demo og deretter bryter sammen foran en ekte bruker første gang de sletter noe fra midten av en liste. Ni av de 23 testene eksisterte utelukkende for å pirke borti disse unntaksveiene.

Ferdighetsarmens 13 tester dekket de samme fire kommandoene på happy-path-nivå, pluss fem unntaksvei-tilfeller: for det meste indekser utenfor rekkevidde og ett duplikat-legg-til-scenario. Hva som mangler i forhold til baseline: ingen eksplisitt test for isolasjon per bruker, og ingen test som bekrefter indeksatferd etter at en sletting forskyver listen. Lagringslogikken i ferdighetsarmens storage.py kan godt håndtere disse tilfellene korrekt. Utestet korrekt atferd og testet korrekt atferd er imidlertid ikke det samme, og hele poenget med en testpakke er å lukke det gapet.

Ingen av pakkene er dårlige. Tretten tester med fem unntakstilfeller på en fire-kommando-bot er et forsvarlig utgangspunkt etter enhver normal ingeniørstandard. Sammenligningen ser bare fordømmende ut ved siden av en baseline som, arbeidet fra en identisk prompt uten rød-grønn stillas i det hele tatt, skrev flere tester, ikke færre.

Hvorfor dette ikke tilbakeviser TDD

Her er det en engangsbetinget benchmark strukturelt ikke kan se: TDDs argument var aldri "du vil skrive flere tester på første forsøk". Det handler om hva som skjer over uker med iterasjon, på tvers av den tiende funksjonen lagt til en kodebase modellen ikke skrev fra bunnen av, på det punktet hvor en sliten ingeniør (eller en agent under tidspress) er fristet til å levere med en rød test og fikse det "senere".

Det er et disiplinpåstand, ikke et engangsresultatpåstand, og denne benchmarken kjørte nøyaktig én gang. Vi kan ikke måle disiplin i en enkelt sesjon fordi disiplin er det som hindrer deg i å ta snarveier i sesjon seks, og det er ingen sesjon seks her.

Vi har et spor av hvordan den disiplinen ser ut i praksis, fra våre egne testnotater på test-driven-development ferdighetssiden: over en tre-funksjons sesjon nektet ferdigheten å hoppe over rød-grønn-syklusen selv når løsningen virket åpenbar og fristelsen til å hoppe rett til grønt var rett der. Den skrev den feilende testen først, så den feile av riktig grunn, og skrev deretter minimumskoden for å bestå den, hver gang, på tvers av alle tre funksjonene. Ingen trengte å gripe inn og si "vent, skriv testen først". Det er oppførselen en disiplinferdighet skal gi, og det er ikke den samme oppførselen som "skriver flere tester i ett forsøk på en liten, veldefinert modul".

På en oppgave av denne størrelsen og så godt spesifisert, var Claude Sonnets baseline-vurdering av hva som skulle testes allerede solid. Ferdigheten la til en eksplisitt prosess på toppen av en vurdering som ennå ikke trengte mye korrigering, og den prosessen kostet 8% flere tokens uten en tilsvarende kvalitetsgevinst i dette spesifikke forsøket. Begge deler kan være sant: TDD er verdt å ha installert, og det hjalp ikke her.

Det er også en enklere forklaring verdt å nevne: å skrive en feilende test, se den feile, og deretter skrive minimumskoden for å bestå den, tar mer frem og tilbake enn å skrive implementeringen og en test for den i ett pass. Den overheaden er poenget med disiplinen når implementeringen ikke er triviell eller modellen er utsatt for å hoppe fremover. På en fire-kommando todo-bot var implementeringen aldri i tvil, så overheaden kjøpte prosess uten å kjøpe en sjekk på noe som faktisk var i fare for å gå galt.

Hva dette betyr hvis du kjøper ferdigheter

Den ubehagelige delen for oss, spesifikt, er at vi selger testede ferdigheter, og vår egen benk viste nettopp en topprangert ferdighet som ikke vant en engangssammenligning mot ingen ferdighet i det hele tatt. Vi vil heller at du ser det enn en høydepunktsrulle.

Den praktiske lærdommen er å matche ferdigheten til jobben, ikke til poengsummen. En 9.6/10 katalogscore betyr at ferdigheten gjør det den sier pålitelig og ikke ødelegger oppsettet ditt, ikke at den vinner hver benchmark på hver oppgavestørrelse. Hvis jobben din er en liten, veldefinert modul du bygger fra bunnen av, i én omgang, kan en sterk modells standardvurdering allerede dekke unntaksveiene du bryr deg om, og en prosessferdighet er overhead du betaler for uten en tilsvarende fordel i den sesjonen. Hvis jobben din er en kodebase du vil berøre i måneder, med flere bidragsytere og lange strekk mellom sesjoner der snarveier akkumuleres i det stille, er det det en disiplinferdighet som TDD er bygget for å forhindre, og en enkelt-sesjons benchmark ville aldri fange den verdien i utgangspunktet.

Hastighetsferdigheter og disiplinferdigheter svarer på forskjellige spørsmål. Les en ferdighets beskrivelse for hvilket spørsmål den svarer på før du installerer den for feil jobb. Vi dekker hvordan du leser det signalet i vår oversikt over de beste kodeferdighetene.

Gjengi det selv

Oppgaven er liten nok til å kjøres på nytt på en ettermiddag. Klon et rent aiogram v3-prosjekt, og kjør deretter den identiske prompten to ganger: én gang i en ren Claude Code-sesjon, én gang med obra/superpowers' test-driven-development-ferdighet installert. Be om /add /list /done /delete med minnebasert lagring per bruker, en storage.py/bot.py-deling, og en pytest-pakke som kjører grønt før du kaller det ferdig. Loggfør totale tokens fra hver sesjons brukssammendrag, og sammenlign deretter de to test_storage.py-filene manuelt: tell påstander, og flagg spesifikt alt som berører negative indekser, manglende nøkler, isolasjon per bruker, og indeksforskyvninger etter en sletting. Disse fire kategoriene er der vi så gapet, og det er de som er verdt å sjekke på enhver todo-stil CRUD-app uavhengig av hvilken ferdighet du tester.

Ofte stilte spørsmål

Betyr dette at TDD-ferdigheten er dårlig?

Nei. Det betyr at en engangsbetinget benchmark på en liten, veldefinert modul ikke er testen som viser hva TDD er til for. Ferdighetens verdi ligger i å forhindre snarveier over en lang sesjon eller et langt prosjekt, noe denne benchmarken, etter design, ikke kjørte lenge nok til å måle.

Hvorfor skrev ferdighetsarmen færre tester hvis den håndhever en strengere prosess?

Rød-grønn-refaktor-sløyfen driver deg til å skrive en test for atferden du er i ferd med å implementere, deretter implementere den, og deretter gå videre til neste atferd. Den ber deg ikke automatisk om å gå tilbake og legge til tester for grensetilfeller ingen eksplisitt ba om, med mindre sesjonen tar tid til å brainstorme dem separat. Baseline-armen, ubegrenset av en fast syklus, brukte tilsynelatende mer av sin output på nettopp den brainstormingen.

Bør jeg installere en TDD-ferdighet for Claude Code?

Hvis du jobber i en kodebase du vil returnere til gjentatte ganger, spesielt med andre bidragsytere eller lange pauser mellom sesjoner, ja. Det er en forsikring mot en spesifikk feilmodus: stille å levere med en rød test fordi løsningen virket åpenbar. Den feilmodusen viser seg ikke i en enkelt ettermiddags benchmark, men den viser seg i virkelige prosjekter.

Hva er neste i denne serien?

Del 3 av "Ferdighetsbenken" ser på en feilsøkingsferdighet mot en umodifisert snake-spill feil jakt. Del 4 reviderer et Google zx automatiseringsskript. Begge følger den samme regelen som denne: samme oppgave, samme modell, én variabel, tallene skrives ut uansett.

Ferdighetsbenken-serien

Del 2 av 4. Les del 1: bygging av landingsside, del 3: feilsøking av snake, og del 4: revisjon av et Google zx-skript.