Hva er Test-Driven Development (TDD)?

Question

Accepted Answer

**Test-Driven Development (TDD)** er en praksis der du skriver **tester før koden** — og følger en kort, repeterende syklus: skriv en test som feiler, skriv kode for å få den til å bestå, deretter refaktor. Det driver design gjennom tester og sikrer at koden er testbar og godt testet.

## TDD-syklusen: Red, Green, Refactor

```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
```

## Eksempelflyt

```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
```

## Fordeler og betraktninger

```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 betyr noe

Å forstå Test-Driven Development er verdifullt fordi det er en **innflytelsesrik, mye diskutert praksis** som former hvordan mange utviklere nærmer seg testing og design, så det er viktig kunnskap for profesjonell utvikling.

TDDs kjerneidé — **skriving av tester før koden**, ved å følge **Red-Green-Refactor-syklusen** (skriv en test som feiler, skriv minimal kode for å få den til å bestå, deretter refaktor mens testene forblir grønne) — er en distinktiv tilnærming som inverterer den vanlige rekkefølgen.

Å forstå syklusen er den viktigste praktiske kunnskapen.

Å forstå **fordelene** forklarer hvorfor TDD blir verdsatt: det sikrer at koden er **testbar** (ved å designe for testing fra starten), **testet** (tester finnes per definisjon), **driver design** (å tenke på atferd og grensesnitt først fører til renere, mer fokusert kode), gir rask tilbakemelding og tillit til å refaktor, unngår overengineering (skrive bare det som trengs for å passere tester), og produserer naturlig god testdekning.

Disse fordelene gjør TDD innflytelsesrik både som en testing- og en designpraksis.

Å forstå **betraktningene** — at TDD er en disiplin som krever praksis, og at det ikke alltid blir anvendt dogmatisk (utviklere bruker dømmekraft om når det passer) — reflekterer et balansert, realistisk syn.

Selvom utviklere som ikke alltid praktiserer TDD drar nytte av å forstå det, fordi det former tenking om testing og design og er et vanlig tema i profesjonell utvikling og intervjuer.

Ettersom TDD er en innflytelsesrik, mye kjent praksis som former testing- og designtilnærminger (med reelle fordeler i testabilitet, design og dekning), og siden det er et vanlig profesjonelt og intervjutema, og siden å forstå syklusen, fordelene og betraktningene reflekterer testmodning, er det verdifullt og relevant å forstå Test-Driven Development — en viktig testingpraksis og filosofi som er verdt å forstå for profesjonell utvikling, innflytelsesrik i hvordan kvalitetsfokuserte utviklere nærmer seg programvareutvikling.