Hvad er Test-Driven Development (TDD)?

Question

Accepted Answer

**Test-Driven Development (TDD)** er en praksis, hvor du skriver **tests før koden** — efter en kort, gentagende cyklus: skriv en test, der fejler, skriv kode for at få den til at bestå, og refaktorér derefter. Det driver design gennem tests og sikrer, at koden er testbar og veltest.

## TDD-cyklus: Rød, Grøn, Refaktorér

```text
1. RED → write a FAILING test for the behavior you want (it fails — the code doesn't exist yet)
2. GREEN → write the MINIMUM code to make the test PASS (just enough, don't over-build)
3. REFACTOR → improve/clean up the code (and tests) while keeping tests GREEN
→ Repeat this short cycle for each small piece of behavior.
```

```text
Write test (RED) → write code (GREEN) → clean up (REFACTOR) → repeat
```

## Eksempelflow

```js
// 1. RED — write the test first (fails: add doesn't exist / is wrong)
test('add(2,3) === 5', () => expect(add(2, 3)).toBe(5));

// 2. GREEN — write minimal code to pass
function add(a, b) { return a + b; }

// 3. REFACTOR — improve if needed (test still passes); then write the next test
```

## Fordele og overvejelser

```text
✓ Ensures code is TESTABLE (you design for testing) and TESTED (tests exist by definition)
✓ Drives DESIGN — thinking about behavior/interface first → cleaner, focused code
✓ Fast FEEDBACK; confidence to refactor; avoids over-engineering (write only what's needed)
✓ Good test coverage as a natural result
⚠️ A discipline/skill that takes practice; not always applied dogmatically (use judgment)
```

## Hvorfor det betyder noget

At forstå Test-Driven Development er værdifuldt, fordi det er en **indflydelsesrig, bredt diskuteret praksis**, der former, hvordan mange udviklere nærmer sig testing og design, så det er vigtig viden for professionel udvikling.

TDDs kerneidé — **at skrive tests før koden**, efter den **Rød-Grøn-Refaktorér-cyklus** (skriv en test, der fejler, skriv minimal kode for at få den til at bestå, refaktorér derefter mens tests forbliver grønne) — er en karakteristisk tilgang, der inverterer den sædvanlige rækkefølge.

At forstå cyklus er den vigtigste praktiske viden.

At forstå **fordelene** forklarer, hvorfor TDD værdsættes: det sikrer, at koden er **testbar** (ved at designe til testing fra starten) og **testet** (tests eksisterer per definition), **driver design** (at tænke på adfærd og interface først fører til renere, mere fokuseret kode), giver hurtig feedback og selvtillid til at refaktorere, undgår overudvikling (at skrive kun det, der er nødvendigt for at bestå tests), og producerer naturligt god testdækning.

Disse fordele gør TDD indflydelsesrig som både en testing- og designpraksis.

At forstå **overvejelserne** — at TDD er en disciplin, der kræver praksis, og at det ikke altid anvendes dogmatisk (udviklere bruger dømmekraft om, hvornår det passer) — afspejler et afbalanceret, realistisk syn.

Selvom udviklere, der ikke altid praktiserer TDD, har gavn af at forstå det, da det former tankegangen om testing og design og er et almindeligt emne inden for professionel udvikling og interviews.

Da TDD er en indflydelsesrig, bredt kendt praksis, der former testing- og designtilgange (med reelle fordele inden for testabilitet, design og dækning) og er et almindeligt professionelt og interview-emne, og da forståelse af cyklus, fordele og overvejelser afspejler testmodenhed, er forståelse af Test-Driven Development værdifuld, relevant viden — en vigtig testingpraksis og filosofi værd at forstå for professionel udvikling, indflydelsesrig i, hvordan kvalitetsfokuserede udviklere nærmer sig at bygge software.