Hva er mocks, stubs og test doubles?

Question

Accepted Answer

**Test doubles** er objekter som erstatter virkelige avhengigheter i tester — inkludert **mocks**, **stubs**, **spies**, **fakes** og **dummies**. De isolerer koden som testes fra avhengighetene (databaser, APIer, tjenester), noe som muliggjør raske, fokuserte og kontrollerte enhetstester.

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

## Typene 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 (nøkkeldistinksjonen)

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

## Hvorfor det er viktig

Å forstå test doubles (mocks, stubs osv.) er viktig fordi de er **essensielle for å skrive isolerte enhetstester**, så det er verdifull, ofte brukt testerkunnskap.

For å teste en enhet isolert (målet med enhetstesting), må du erstatte de virkelige avhengighetene (databaser, APIer, tjenester) med **test doubles** — noe som muliggjør tester som er **raske** (ingen virkelig I/O), **kontrollerte** (setting opp nøyaktige scenarier inkludert feilbetingelser som er vanskelige å utløse med virkelige avhengigheter), og **deterministiske** (ingen ekstern ustabilitet).

Å forstå **typene** og deres formål er nødvendig: **stubs** (som gir forhåndsdefinerte svar for å kontrollere hva avhengigheter returnerer — som mater enheten spesifikke data), **mocks** (stubs som også verifiserer interaksjoner — som sjekker at enheten kalte en avhengighet korrekt), **spies** (som registrerer kall på virkelige eller falske objekter), **fakes** (som fungerer forenklet som implementasjoner, for eksempel in-memory databaser), og **dummies** (som er plassholdere).

Å forstå **nøkkeldistinksjonen mellom mock og stub** — stubs kontrollerer input (tilstandsverifisering: som gir data) mens mocks verifiserer utdata/interaksjoner (atferdsverifisering: som sjekker at enheten kalte avhengigheter korrekt) — er viktig konseptuell kunnskap som ofte blir forvekslet, og å bruke hver enkelt på riktig måte er viktig.

Å forstå **over-mocking-fellen** (overdreven mocking knytter tester til implementeringsdetaljer, noe som gjør dem skjøre, så du bør mock ved de rette grensene) gjenspeiler modent testdomskunnskaper.

Test doubles brukes konstant i enhetstesting for å isolere koden som testes.

Ettersom isolert enhetstesting krever at du erstatter virkelige avhengigheter med test doubles (for hastighet, kontroll og determinisme), og siden å forstå typene, mock-vs-stub-distinksjonen og over-mocking-fellen er nødvendig for å skrive gode isolerte tester, er å forstå test doubles verdifull, ofte brukt testerkunnskap — essensielt for enhetstesting, brukt konstant for å isolere koden som testes, og viktig for å skrive fokuserte, kontrollerte tester samtidig som du unngår skjørheten ved over-mocking, en kjerneferdighet for effektiv enhetstesting.