Mi azok a test fixture-k és a setup/teardown?

Question

Accepted Answer

**A test fixture-k** az a rögzített felépítés (adatok, objektumok, állapot), amelyre a teszteknek szükségük van a futásához, és a **setup/teardown** metódusok ezt a kontextust készítik elő és tisztítják meg a tesztek előtt és után. Csökkentik a duplikációt és biztosítják, hogy a tesztek konzisztens, izolált állapotban fussanak.

## Setup és 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 */ });
});
```

## Fixture-k — újrahasználható tesztadatok/állapot

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

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

## Miért fontos

A test fixture-k és a setup/teardown megértése értékes, mivel **alapvetőek a tiszta, izolált, karbantartható tesztek írásához**, ezért praktikus és hasznos tudás.

A teszteknek konzisztens kezdő kontextusra van szükségük (adatok, objektumok, állapot), és a **setup/teardown** metódusok (a `beforeEach`/`afterEach` és `beforeAll`/`afterAll` hookok, amelyeket a keretrendszerek biztosítanak) ezt a kontextust készítik elő a tesztek előtt és tisztítják meg után — csökkentve a duplikációt (a megosztott setup egyszer van megírva, nem minden tesztben) és biztosítva, hogy a tesztek ismert állapotban fussanak.

Annak megértése, hogy mely hookökat mikor használjuk (beforeEach az minden tesztre vonatkozó friss állapothoz, beforeAll a drága megosztott felépítéshez), szükséges a tesztek jó szervezéséhez.

A **fixture-k** (elődefiniált tesztadatok és objektumok, amelyek egy ismert kezdő állapotot adnak a teszteknek) és a **factory-k** (rugalmas tesztadatok generálása ésszerű alapértékekkel és felülírásokkal, jobb, mint keményen kódolt adatok különféle forgatókönyvekhez) megértése értékes a tesztek konzisztens, kezelhető adatokkal való ellátásához.

A legfontosabb, hogy a **best practice-ek** megértése a tesztminőséghez kapcsolódik: a **per-test friss állapot** előnyben részesítésével biztosított `beforeEach` az **izolációt** (a tesztek nem befolyásolják egymást — kritikus a megbízható tesztek számára), a **teardown-ban való takarítás** megakadályozza az olyan maradék állapotot, amely instabil, sorrendfüggő teszteket okoz (az instabilitás közös forrása), és az **mutálható állapot megosztásának elkerülése** a tesztek között elkerüli a sorrendfüggőséget és az instabilitást.

Ezek a gyakorlatok közvetlenül támogatják a tesztizoláció és determinizmust, amelyre a jó tesztek szükségletes.

Mivel a tesztek konzisztens felépítést és takarítást igényelnek, és mivel a fixture-k és a setup/teardown (jól használva, megfelelő izolációval és takarítással) csökkentik a duplikációt és biztosítják az izolált, determinisztikus állapotot, amelytől a megbízható tesztek függenek, a test fixture-k és a setup/teardown megértése értékes, gyakorlatilag releváns tudás — fontos a tiszta, izolált, karbantartható tesztek írásához, közvetlenül támogatva az izolációt és determinizmust, amely megbízható teszteket különböztet meg az instabil testektől, hasznos készség, amelyet gyakorlatilag minden tesztcsomag szervezésénél alkalmaznak.