Testgenerering och standarder

En monolitisk CLAUDE.md blir svårläst och förbrukar kontext. Flytta den detaljerade testmanualen till en egen fil och importera den med syntaxen @path. Då hålls rotfilen kort samtidigt som standarden fortfarande läses in.

Den importerade filen är vanlig markdown och versionshanteras som allt annat, så standarden kan återanvändas och enkelt granskas separat.

Ännu bättre än importer som alltid är aktiva är att lägga testkonventioner i en fil i .claude/rules/ med YAML-frontmatter och paths. Regeln läses in endast när matchande filer redigeras, så ni sparar kontext och tokens jämfört med en monolitisk CLAUDE.md som skickar med allt vid varje tur.

Begränsa regeln till er testkatalog så aktiveras den exakt när Claude genererar eller redigerar tester, och håller sig annars ur vägen.

Den överlägset vanligaste orsaken till dåliga genererade tester är påhittade fixtures: modellen hittar på ett användarobjekt eller en DB-stubb i stället för att använda era. Dokumentera de riktiga fixturerna så att Claude återanvänder dem.

Beskriv tydligt vad varje fixture tillhandahåller, dess struktur och när den ska användas. Se detta som en verktygsbeskrivning: syfte, returvärde, indataformat och gränser för användbarhet är det som styr rätt val.

Enbart löptext lämnar utrymme för tvetydighet. Lägg till 2 till 4 riktade exempel på ett kanoniskt test så att modellen generaliserar mönstret i stället för att bara kopiera det. Few-shot-exempel är det effektivaste sättet att skapa konsekvens, hantera specialfall och styra utdataformatet.

Visa ett komplett, idiomatiskt test som använder era riktiga fixtures. Nya tester kommer att efterlikna dess struktur, namngivning och assertion-stil.

"Write good tests" är ett vagt önskemål. Tydliga kriterier ger tillförlitlig utdata. Jämför "be thorough" med "cover the happy path, one boundary value, and one error path; never test private methods directly."

Konkreta, kontrollerbara regler tar bort de gissningar som gör att genererade tester blir inkonsekventa mellan filer och personer som bidrar.

Gör arbetsflödet repeterbart med en Skill i .claude/skills/ (projektomfattning delas via VCS, medan användaromfattning är personlig). Skillen samlar er standard och kan begränsa verktyg samt isolera utdata.

Använd context: fork för att isolera utförlig genereringsutdata, allowed-tools för att begränsa vad den får påverka och argument-hint för att vägleda den som anropar den. Nu är "generate tests to standard" ett återanvändbart kommando i stället för ett stycke som måste skrivas om.

Generera inte i ett vakuum. Låt Claude först följa mönstret stegvis undersökning: använd Glob för att hitta befintliga testfiler, Read för att läsa ett par av dem, Grep för att se hur en fixture används och skriv sedan ett nytt test som passar in bland de befintliga.

Att förankra genereringen i den verkliga kodbasen slår att rabbla en stilguide, eftersom modellen kopierar levande, fungerande konventioner i stället för att gissa.

I en pipeline genererar ni tester headless med -p (obligatoriskt eftersom ingen människa är närvarande) och --output-format json, så att ett senare steg kan tolka resultatet. Granska sedan de genererade testerna i en separat, isolerad session.

Granskning i en ny instans slår självgranskning i samma session: upphovspersonen behåller sitt eget resonemang och kommer inte att ifrågasätta sina egna tester. En ren granskare upptäcker tautologiska assertioner och saknade felvägar som generatorn missade.

När ni ber om tester i strukturerat format (tool_use + JSON Schema) ska ni validera resultatet. Om det är felaktigt formaterat använder ni retry-with-feedback: skicka den ursprungliga begäran, den felaktiga utdatan och det exakta valideringsfelet igen. Det rättar till format- och strukturfel på ett tillförlitligt sätt.

Två varningar från faktabladet: retry hjälper INTE när den information som behövs helt enkelt saknas i källan, och ett schemafält ska markeras som required endast om det alltid finns med, annars kommer modellen att hitta på det.

Viktiga slutsatser:

• Placera teststandarder på projektnivå (./CLAUDE.md, .claude/rules/ med paths) och dela dem via VCS. Förlita er aldrig på personlig ~/.claude/CLAUDE.md i CI.
• Modularisera med @path-importer. Regler med frontmatter och paths läses endast in när matchande filer redigeras, vilket sparar kontext.
• Dokumentera fixtures som sanningskälla (syfte, struktur och när de ska användas), så att modellen återanvänder dem i stället för att hitta på stubbar.
• Few-shot (2–4 kanoniska exempel) tillsammans med tydliga kriterier slår vaga instruktioner; modellen generaliserar mönstret.
• Samla allt i en Skill i .claude/skills/ och låt Claude undersöka befintliga tester (Glob/Read/Grep) innan nya skrivs.
• I CI genererar ni headless med -p --output-format json och granskar sedan i en ny, isolerad session.
• Validera strukturerad utdata. retry-with-feedback rättar formatfel men inte saknad information, och ett schemafält ska endast krävas om det alltid finns med.