Mitä ovat mockit, stubbit ja test doubles?

Question

Accepted Answer

**Test doubles** ovat objekteja, jotka korvaavat todellisia riippuvuuksia testeissä — mukaan lukien **mockit**, **stubbit**, **spyit**, **fakeit** ja **dummyt**. Ne eristävät testattavan koodin sen riippuvuuksista (tietokannat, API:t, palvelut), jolloin voidaan kirjoittaa nopeita, keskitettyjä, hallittuja yksikkötestejä.

## Miksi test doubles ovat tärkeitä

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

## Test doublen tyypit

```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 (ratkaiseva ero)

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

## Miksi se on tärkeää

Test doublen ymmärtäminen (mockit, stubbit jne.) on tärkeää, koska ne ovat **välttämättömiä eristettyjen yksikkötestien kirjoittamiseen**, joten se on arvokas, usein käytetty testaustieto.

Yksikön testaamiseksi eristyksissä (yksikkötestauksen tavoite) sinun on korvattava sen todelliset riippuvuudet (tietokannat, API:t, palvelut) **test doublella** — jolloin testit ovat **nopeita** (ei todellista I/O:ta), **hallittuja** (tarkkaan määritellyt skenaariot, mukaan lukien virhetilanteet, jotka ovat vaikea laukaista todellisilla riippuvuuksilla) ja **deterministisia** (ei ulkoista epävakautta).

**Tyyppien** ja niiden tarkoitusten ymmärtäminen on välttämätöntä: **stubbit** (ennalta määrättyjen vastausten toimittaminen riippuvuuksien tuotoksen hallitsemiseksi — tarjoamalla yksikölle tietyt tiedot), **mockit** (stubbit, jotka myös varmistavat vuorovaikutuksen — tarkistavat, että yksikkö kutsui riippuvuutta oikein), **spyit** (kutsut tallentavat todellisille tai väärille objekteille), **fakeit** (toimivat yksinkertaistetut toteutukset, kuten muistissa olevat tietokannat) ja **dummyt** (paikanpitäjät).

**Ratkaisevaa mock-vs-stub-eroa** ymmärtäminen — stubbit hallitsevat syötteitä (tilanvarifiointi: tietojen toimittaminen), kun taas mockit varmistavat tulokset/vuorovaikutukset (käyttäytymisen varmennus: tarkistetaan, että yksikkö kutsui riippuvuuksia oikein) — on tärkeä käsitteellinen tieto, joka usein sekoitetaan, ja kummankin asianmukainen käyttö on olennaista.

**Liiallisen mockauksen sudenkuopan** ymmärtäminen (liiallinen mockailu sitoo testit toteutusyksityiskohtiin, mikä tekee niistä hauraita, joten sinun tulisi mockata oikeissa rajoissa) heijastaa kypsää testausosaamista.

Test doubleja käytetään jatkuvasti yksikkötestikäytännössä koodin eristämiseen.

Koska eristetty yksikkötestaus vaatii todellisten riippuvuuksien korvaamisen test doublella (nopeuden, hallinnan ja determinismin vuoksi) ja koska tyyppien, mock-vs-stub-eron ja liiallisen mockauksen sudenkuopan ymmärtäminen on välttämätöntä hyville eristetyn testille, test doublen ymmärtäminen on arvokas, usein käytetty testaustieto — välttämätön yksikkötestauksen kannalta, käytetään jatkuvasti koodin eristämiseen ja tärkeä fokusoiduille, hallituille testeille, samalla kun vältetään liiallisen mockkailun aiheuttamaa haurautta, mikä on ydinasia tehokkaalle yksikkötestaukselle.