Testdrevet utvikling — test-first, red-green-refactor, bugfiks med reproduksjonstest og ny funksjonalitet med tester først. Brukes via /tdd ved testdrevet arbeidsflyt.
Install
mkdir -p .claude/skills/tdd-navikt && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/13406" && unzip -o skill.zip -d .claude/skills/tdd-navikt && rm skill.zipInstalls to .claude/skills/tdd-navikt
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Testdrevet utvikling — test-first, red-green-refactor, bugfiks med reproduksjonstest og ny funksjonalitet med tester først. Brukes via /tdd ved testdrevet arbeidsflyt.About this skill
Testdrevet utvikling
Filosofi
Kjerneprinsipp: Tester verifiserer atferd gjennom offentlige grensesnitt, ikke implementasjonsdetaljer. Koden kan endres totalt — testene skal overleve.
Gode tester tester gjennom offentlige API-er. De beskriver hva systemet gjør. "Bruker kan sende søknad med gyldig skjema" forteller nøyaktig hvilken funksjon som finnes. Disse testene overlever refaktoreringer fordi de ikke bryr seg om intern struktur.
Dårlige tester er koblet til implementasjon. De mocker interne samarbeidspartnere, tester private metoder, eller verifiserer gjennom eksterne mekanismer. Varseltegn: testen feiler ved refaktorering, men atferden er uendret.
Anti-mønster: Horisontale skiver
IKKE skriv alle tester først, deretter all implementasjon. Det er å behandle RED som "skriv alle tester" og GREEN som "skriv all kode."
FEIL (horisontalt):
RED: test1, test2, test3, test4, test5
GREEN: impl1, impl2, impl3, impl4, impl5
RIKTIG (vertikalt):
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
RED→GREEN: test3→impl3
Arbeidsflyt
1. Planlegg
- Avklar med bruker hvilke grensesnittendringer som trengs
- Avklar hvilke atferder som skal testes (prioriter)
- List atferdene som skal testes (ikke implementasjonssteg)
- Få brukerens godkjenning
Spør: "Hvilket grensesnitt skal vi eksponere? Hvilke atferder er viktigst å teste?"
2. Tracer bullet
Skriv ÉN test som bekrefter ÉN ting om systemet:
RED: Skriv test → feiler
GREEN: Minimal kode for å bestå → bestått
3. Inkrementell loop
For hver gjenværende atferd:
RED: Neste test → feiler
GREEN: Minimal kode → bestått
Regler:
- Én test om gangen
- Bare nok kode til å bestå gjeldende test
- Ikke forutse fremtidige tester
- Fokus på observerbar atferd
4. Refaktorer
Etter at alle tester består:
- Ekstraher duplisering
- Flytt kompleksitet bak enkle grensesnitt
- Kjør tester etter hvert refaktoreringssteg
Aldri refaktorer mens RED. Kom til GREEN først.
Sjekkliste per syklus
[ ] Test beskriver atferd, ikke implementasjon
[ ] Test bruker kun offentlig grensesnitt
[ ] Test ville overlevd intern refaktorering
[ ] Kode er minimal for denne testen
[ ] Ingen spekulative funksjoner lagt til
Mocking
- Mock ved systemgrenser (HTTP, database, filsystem), ikke mellom interne moduler
- Hvis du må mocke en intern samarbeidspartner, er modulgrensen feil
- Foretrekk dependency injection over monkey-patching