What are test fixtures and setup/teardown?

Question

Accepted Answer

**Test fixtures** are the fixed setup (data, objects, state) that tests need to run, and **setup/teardown** methods prepare and clean up this context before and after tests. They reduce duplication and ensure tests run in a consistent, isolated state.

## Setup and 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 — reusable test data/state

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

## Why it matters

Understanding test fixtures and setup/teardown is valuable because they're **essential for writing clean, isolated, maintainable tests**, so it's useful practical knowledge.

Tests need a consistent starting context (data, objects, state), and **setup/teardown** methods (the `beforeEach`/`afterEach` and `beforeAll`/`afterAll` hooks frameworks provide) prepare this context before tests and clean it up after — reducing duplication (shared setup written once rather than in every test) and ensuring tests run in a known state.

Understanding these hooks and when to use each (beforeEach for fresh per-test state, beforeAll for expensive shared setup) is necessary for organizing tests well.

Understanding **fixtures** (predefined test data and objects giving tests a known starting state) and **factories** (generating test data flexibly with sensible defaults and overrides, better than hardcoded data for varied scenarios) is valuable for providing tests with consistent, manageable data.

Most importantly, understanding the **best practices** connects to test quality: preferring `beforeEach` for **fresh state per test** ensures **isolation** (tests don't affect each other — crucial for reliable tests), **cleaning up in teardown** prevents leftover state that causes flaky, order-dependent tests (a common source of flakiness), and **not sharing mutable state across tests** avoids order-dependence and flakiness.

These practices directly support the test isolation and determinism that good tests require.

Since tests need consistent setup and cleanup, and since fixtures and setup/teardown (used well, with proper isolation and cleanup) reduce duplication and ensure the isolated, deterministic state that reliable tests depend on, understanding test fixtures and setup/teardown is valuable, practically-relevant knowledge — important for writing clean, isolated, maintainable tests, directly supporting the isolation and determinism that distinguish reliable tests from flaky ones, a useful skill applied in organizing virtually every test suite.