Hvad er test fixtures og setup/teardown?

Question

Accepted Answer

**Test fixtures** er det faste setup (data, objekter, tilstand), som tests har brug for til at køre, og **setup/teardown** metoder forbereder og rydder op i denne kontekst før og efter tests. De reducerer duplikering og sikrer, at tests køres i en konsistent, isoleret tilstand.

## Setup og teardown

```text
SETUP → runs BEFORE tests to prepare the context (create objects, data, connections)
TEARDOWN → runs AFTER tests to CLEAN UP (close connections, delete data, reset state)
→ frameworks provide hooks:
  beforeEach / afterEach → before/after EACH test (fresh state per test — common)
  beforeAll / afterAll → once before/after ALL tests in a group (shared expensive setup)
```

```js
describe('UserService', () => {
  let service, db;
  beforeEach(() => {                 // fresh setup for EACH test (isolation)
    db = createTestDb();
    service = new UserService(db);
  });
  afterEach(() => db.close());        // clean up after each test

test('creates a user', () => { /* uses the fresh service/db */ });
});
```

## Fixtures — genanvendelig testdata/tilstand

```text
FIXTURES → predefined data/objects tests use (a known starting state):
  → e.g. a sample user, a set of records, a configured object
  → FACTORIES → generate test data flexibly (build objects with sensible defaults +
    overrides) — better than hardcoded data for varied scenarios
→ reduce duplication; give tests consistent, known data to work with
```

## Best practices

```text
✓ Prefer beforeEach (fresh state per test) → ISOLATION (tests don't affect each other)
✓ Clean up in teardown → no leftover state causing flaky/order-dependent tests
✓ Keep setup minimal and clear; use factories for flexible test data
✓ Don't share MUTABLE state across tests (a cause of flakiness/order-dependence)
```

## Hvorfor det betyder noget

At forstå test fixtures og setup/teardown er værdifuldt, fordi de er **vigtige for at skrive rene, isolerede, vedligeholdelige tests**, så det er praktisk brugbar viden.

Tests har brug for en konsistent startopstilling (data, objekter, tilstand), og **setup/teardown** metoder (de `beforeEach`/`afterEach` og `beforeAll`/`afterAll` hooks, som frameworks leverer) forbereder denne kontekst før tests og rydder op efter — hvilket reducerer duplikering (delt setup skrevet en gang i stedet for i hver test) og sikrer, at tests køres i en kendt tilstand.

At forstå disse hooks og hvornår man bruger hver enkelt (beforeEach for frisk per-test tilstand, beforeAll for dyr delt setup) er nødvendigt for at organisere tests godt.

At forstå **fixtures** (foruddefineret testdata og objekter, der giver tests en kendt starttilstand) og **factories** (generering af testdata fleksibelt med fornuftige standarder og overstyringer, bedre end hardcodet data til varierede scenarier) er værdifuldt for at give tests konsistent, håndterbar data.

Mest vigtigt forbinder forståelsen af **best practices** til testkvalitet: foretrække `beforeEach` for **frisk tilstand pr. test** sikrer **isolation** (tests påvirker ikke hinanden — afgørende for pålidelige tests), **rydde op i teardown** forhindrer efterladt tilstand, der forårsager skør, afhængig-af-rækkefølge tests (en almindelig kilde til skørhed), og **ikke dele mutable tilstand på tværs af tests** undgår afhængighed af rækkefølge og skørhed.

Disse praksisser understøtter direkte test isolation og determinisme, som gode tests kræver.

Da tests har brug for konsistent setup og cleanup, og da fixtures og setup/teardown (brugt godt, med korrekt isolation og cleanup) reducerer duplikering og sikrer den isolerede, deterministiske tilstand, som pålidelige tests er afhængige af, er forståelse af test fixtures og setup/teardown værdifuld, praktisk-relevant viden — vigtig for at skrive rene, isolerede, vedligeholdelige tests, direkte understøttende isolation og determinisme, som skelner pålidelige tests fra skøre, en brugbar færdighed anvendt ved organisering af praktisk talt hvert testsuite.