Hva er testfixturer og setup/teardown?

Question

Accepted Answer

**Testfixturer** er den faste oppsetningen (data, objekter, tilstand) som tester trenger for å kjøre, og **setup/teardown**-metoder forbereder og rydder opp i denne konteksten før og etter tester. De reduserer duplisering og sikrer at tester kjøres i en konsistent, isolert 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 */ });
});
```

## Fixturer — gjenbrukbar 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
```

## Beste praksis

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

Å forstå testfixturer og setup/teardown er verdifullt fordi de er **essensielle for å skrive rene, isolerte, vedlikeholdbare tester**, så det er nyttig praktisk kunnskap.

Tester trenger en konsistent startkontekst (data, objekter, tilstand), og **setup/teardown**-metoder (hooken `beforeEach`/`afterEach` og `beforeAll`/`afterAll` som rammeverk tilbyr) forbereder denne konteksten før tester og rydder opp etter — noe som reduserer duplisering (delt setup skrevet en gang i stedet for i hver test) og sikrer at tester kjøres i en kjent tilstand.

Å forstå disse hooken og når hver skal brukes (beforeEach for frisk tilstand per test, beforeAll for dyrt delt setup) er nødvendig for å organisere tester godt.

Å forstå **fixturer** (forhåndsdefinert testdata og objekter som gir tester en kjent starttilstand) og **fabrikker** (generering av testdata fleksibelt med fornuftige standarder og overstyringer, bedre enn hardkodet data for varierte scenarioer) er verdifullt for å gi tester konsistent, håndterbar data.

Mest viktig er at å forstå **beste praksis** forbinder seg til testkvalitet: å foretrekke `beforeEach` for **frisk tilstand per test** sikrer **isolasjon** (tester påvirker ikke hverandre — avgjørende for pålitelige tester), **rydding i teardown** forhindrer gjenværende tilstand som forårsaker ustabile, rekkefølgeavhengige tester (en vanlig kilde til ustabilitet), og **å ikke dele muterbar tilstand på tvers av tester** unngår rekkefølgeavhengighet og ustabilitet.

Disse praksisene støtter direkte testisoleringen og determinismen som gode tester krever.

Ettersom tester trenger konsistent setup og rydding, og siden fixturer og setup/teardown (brukt godt, med riktig isolasjon og rydding) reduserer duplisering og sikrer den isolerte, deterministiske tilstanden som pålitelige tester er avhengige av, er det verdifullt, praktisk relevant kunnskap å forstå testfixturer og setup/teardown — viktig for å skrive rene, isolerte, vedlikeholdbare tester, noe som direkte støtter isolasjonen og determinismen som skiller pålitelige tester fra ustabile, en nyttig ferdighet brukt ved organisering av praktisk talt alle testpakker.