Wat zijn test fixtures en setup/teardown?

Question

Accepted Answer

**Test fixtures** zijn de vaste opstelling (data, objecten, toestand) die tests nodig hebben om uit te voeren, en **setup/teardown** methoden bereiden deze context voor en ruimen deze op voor en na tests. Ze verminderen duplicatie en zorgen ervoor dat tests in een consistente, geïsoleerde toestand worden uitgevoerd.

## Setup en 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 — herbruikbare testdata/toestand

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

## Waarom het belangrijk is

Inzicht in test fixtures en setup/teardown is waardevol omdat ze **essentieel zijn voor het schrijven van schone, geïsoleerde, onderhoudbare tests**, dus het is nuttige praktische kennis.

Tests hebben een consistente startcontext nodig (data, objecten, toestand), en **setup/teardown** methoden (de `beforeEach`/`afterEach` en `beforeAll`/`afterAll` hooks die frameworks bieden) bereiden deze context voor tests voor en ruimen deze erna op — duplicatie verminderend (gedeelde setup eenmaal geschreven in plaats van in elke test) en zorgende dat tests in een bekende toestand worden uitgevoerd.

Inzicht in deze hooks en wanneer elk te gebruiken (beforeEach voor verse per-test toestand, beforeAll voor dure gedeelde setup) is noodzakelijk voor het goed organiseren van tests.

Inzicht in **fixtures** (voorgedefinieerde testdata en objecten die tests een bekende starttoestand geven) en **factories** (flexibel testdata genereren met verstandige standaardwaarden en overrides, beter dan hardcoded data voor varieerde scenario's) is waardevol voor het voorzien van tests van consistente, beheerbare data.

Het allerbelangrijkste is dat inzicht in **best practices** aansluit bij testkwaliteit: voorkeur voor `beforeEach` voor **verse toestand per test** zorgt voor **isolatie** (tests beïnvloeden elkaar niet — cruciaal voor betrouwbare tests), **opruimen in teardown** voorkomt resterende toestand die flaky, order-afhankelijke tests veroorzaakt (een veelvoorkomende bron van flakiness), en **niet het delen van veranderbare toestand tussen tests** vermijdt order-afhankelijkheid en flakiness.

Deze praktijken ondersteunen direct de test-isolatie en determinisme die goede tests vereisen.

Omdat tests consistente setup en opschoning nodig hebben, en omdat fixtures en setup/teardown (goed gebruikt, met juiste isolatie en opschoning) duplicatie verminderen en de geïsoleerde, deterministische toestand zorgen waarvan betrouwbare tests afhangen, is inzicht in test fixtures en setup/teardown waardevol, praktisch relevante kennis — belangrijk voor het schrijven van schone, geïsoleerde, onderhoudbare tests, direct ondersteunende de isolatie en determinisme die betrouwbare tests van flaky tests onderscheiden, een nuttige vaardigheid toegepast in het organiseren van vrijwel elke testsuite.