Supports TDD workflows with red-green-refactor cycles. Focuses on testing public interfaces for robust software.
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.Key capabilities
- →Clarify interface changes with the user
- →List behaviors to be tested
- →Write one test to confirm one system aspect
- →Incrementally add tests and minimal code to pass them
- →Refactor after all tests pass
How it works
The skill guides a Test-Driven Development (TDD) workflow, emphasizing test-first, red-green-refactor cycles, and testing through public APIs.
Inputs & outputs
When to use tdd
- →Run TDD red-green cycle
- →Write tests for new features
- →Reproduce bugs with failing tests
- →Refactor existing logic safely
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
When not to use it
- →When writing all tests first before any implementation
- →When refactoring while tests are failing (RED state)
- →When mocking internal collaborators instead of system boundaries
Limitations
- →Tests must describe behavior, not implementation details.
- →Tests must use only public interfaces.
- →Refactoring is only allowed when all tests pass (GREEN state).
How it compares
This skill enforces a vertical, incremental TDD workflow, focusing on testing behavior through public interfaces and refactoring only in the GREEN state, unlike a horizontal approach or testing implementation details.
Compared to similar skills
tdd side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| tdd (this skill) | 0 | 3mo | No flags | Intermediate |
| tdd-workflow | 6 | 4mo | Review | Intermediate |
| qlty-check | 5 | 7mo | Review | Beginner |
| superpowers-tdd | 5 | 6mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by navikt
View all by navikt →You might also like
tdd-workflow
affaan-m
在编写新功能、修复错误或重构代码时使用此技能。强制执行测试驱动开发，包含单元测试、集成测试和端到端测试，覆盖率超过80%。
qlty-check
parcadei
Code quality checks, formatting, and metrics via qlty CLI
superpowers-tdd
anthonylee991
Applies tests-first discipline (red/green/refactor) and adds regression tests for bugs. Use when implementing features, fixing bugs, or refactoring.
solid
ramziddin
Use this skill when writing code, implementing features, refactoring, planning architecture, designing systems, reviewing code, or debugging. This skill transforms junior-level code into senior-engineer quality software through SOLID principles, TDD, clean code practices, and professional software design.
bunit-test-migration
FritzAndFriends
Migrate bUnit test files from deprecated beta API (1.0.0-beta-10) to bUnit 2.x stable API. Use this when working on .razor test files in BlazorWebFormsComponents.Test that contain old patterns like TestComponentBase, Fixture, or SnapshotTest.
code-refactor
luongnv89
Systematic code refactoring based on Martin Fowler's methodology. Use when users ask to refactor code, improve code structure, reduce technical debt, clean up legacy code, eliminate code smells, or improve code maintainability. This skill guides through a phased approach with research, planning, and safe incremental implementation.