Vad är mocks, stubs och test doubles?

Question

Accepted Answer

**Test doubles** är objekt som ersätter verkliga beroenden i tester — inklusive **mocks**, **stubs**, **spies**, **fakes** och **dummies**. De isolerar koden under test från dess beroenden (databaser, API:er, tjänster), vilket möjliggör snabba, fokuserade och kontrollerade enhetstester.

## Varför test doubles

```text
To test a unit in ISOLATION, replace its real dependencies (DB, API, services) with
TEST DOUBLES (fake stand-ins):
  → isolate the unit (test ONLY it, not its dependencies)
  → FAST (no real DB/network); CONTROLLED (set up exact scenarios, including errors);
    DETERMINISTIC (no external flakiness)
```

## Typerna av test doubles

```text
STUB → provides canned RESPONSES to calls (returns preset data):
  → "when getUser is called, return this fake user" — controls inputs to the unit
MOCK → a stub that also VERIFIES interactions (was it called? how? with what?):
  → "verify save() was called once with these arguments" — checks behavior/interactions
SPY → wraps a real (or fake) object and RECORDS calls (verify how it was used)
FAKE → a working but simplified implementation (e.g. an in-memory database)
DUMMY → a placeholder passed but not actually used
```

```js
// stub: control what a dependency returns
const userService = { getUser: jest.fn().mockReturnValue({ name: 'Ann' }) };
// mock verification: check an interaction happened
expect(emailService.send).toHaveBeenCalledWith('ann@x.com');
```

## Mock vs stub (nyckelskilnaden)

```text
STUB → controls INPUTS (provides data the unit needs) — "state" verification
MOCK → verifies OUTPUTS/interactions (was the dependency called correctly?) — "behavior"
  verification
→ Use stubs to provide data; mocks to verify the unit called a dependency correctly.
⚠️ Over-mocking → tests coupled to implementation (brittle); mock at the right boundaries.
```

## Varför det är viktigt

Att förstå test doubles (mocks, stubs, etc.) är viktigt eftersom de är **väsentliga för att skriva isolerade enhetstester**, så det är värdefull, ofta använd testkunskap.

För att testa en enhet isolerat (målet med enhetstestning) måste du ersätta dess verkliga beroenden (databaser, API:er, tjänster) med **test doubles** — vilket möjliggör tester som är **snabba** (ingen verklig I/O), **kontrollerade** (ställer in exakta scenarier inklusive felförhållanden som är svåra att utlösa med verkliga beroenden) och **deterministiska** (ingen extern instabilitet).

Att förstå **typerna** och deras syften är nödvändigt: **stubs** (tillhandahåller färdiga svar för att styra vad beroenden returnerar — matar enheten specifik data), **mocks** (stubs som även verifierar interaktioner — kontrollerar att enheten anropade ett beroende korrekt), **spies** (registrerar anrop på verkliga eller falska objekt), **fakes** (fungerar förenklade implementeringar som minnesdatabaser) och **dummies** (platshållare).

Att förstå **nyckelskillnaden mellan mock och stub** — stubs styr indata (tillståndsverifiering: tillhandahåller data) medan mocks verifierar utdata/interaktioner (beteendeverifiering: kontrollerar att enheten anropade beroenden korrekt) — är viktig konceptuell kunskap som ofta förväxlas, och att använda var och en lämpligt är viktigt.

Att förstå **över-mocking-fällan** (överdriven mocking kopplar tester till implementeringsdetaljer, vilket gör dem bräckliga, så du bör mocka vid rätt gränser) återspeglar mogen testningsdomän.

Test doubles används ständigt i enhetstestning för att isolera koden under test.

Since isolated unit testing requires replacing real dependencies with test doubles (for speed, control, and determinism), and since understanding the types, the mock-vs-stub distinction, and the over-mocking pitfall is necessary to write good isolated tests, understanding test doubles is valuable, frequently-applied testing knowledge — essential for unit testing, used constantly to isolate code under test, and important for writing focused, controlled tests while avoiding the brittleness of over-mocking, a core skill for effective unit testing.