Cosa sono i mock, gli stub e i test double?

Question

Accepted Answer

I **test double** sono oggetti che sostituiscono le dipendenze reali nei test — inclusi **mock**, **stub**, **spy**, **fake** e **dummy**. Isolano il codice sotto test dalle sue dipendenze (database, API, servizi), consentendo unit test veloci, focalizzati e controllati.

## Perché è importante

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

## I tipi di test double

```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 (la distinzione fondamentale)

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

## Perché è importante

Comprendere i test double (mock, stub, ecc.) è importante perché sono **essenziali per scrivere unit test isolati**, quindi rappresentano una conoscenza di testing preziosa e frequentemente applicata.

Per testare un'unità in isolamento (l'obiettivo dello unit testing), è necessario sostituire le sue dipendenze reali (database, API, servizi) con **test double** — consentendo test che sono **veloci** (nessun I/O reale), **controllati** (configurando scenari esatti incluse condizioni di errore difficili da attivare con dipendenze reali) e **deterministici** (nessuna flakiness esterna).

Comprendere i **tipi** e i loro scopi è necessario: **stub** (fornire risposte predefinite per controllare cosa restituiscono le dipendenze — alimentare l'unità con dati specifici), **mock** (stub che verificano anche le interazioni — controllare che l'unità abbia chiamato una dipendenza correttamente), **spy** (registrare le chiamate su oggetti reali o fake), **fake** (implementazioni semplificate funzionanti come database in-memory), e **dummy** (segnaposti).

Comprendere la **distinzione fondamentale mock-vs-stub** — gli stub controllano gli input (verifica dello stato: fornire dati) mentre i mock verificano gli output/le interazioni (verifica del comportamento: controllare che l'unità abbia chiamato le dipendenze correttamente) — è una conoscenza concettuale importante spesso confusa, e usare correttamente ciascuno è importante.

Comprendere il **pitfall dell'over-mocking** (il mocking eccessivo accoppia i test ai dettagli di implementazione, rendendoli fragili, quindi è necessario mockare ai confini giusti) riflette un giudizio di testing maturo.

I test double sono usati costantemente nello unit testing per isolare il codice sotto test.

Poiché lo unit testing isolato richiede di sostituire le dipendenze reali con test double (per velocità, controllo e determinismo), e poiché comprendere i tipi, la distinzione mock-vs-stub e il pitfall dell'over-mocking è necessario per scrivere buoni test isolati, comprendere i test double è una conoscenza di testing preziosa e frequentemente applicata — essenziale per lo unit testing, usata costantemente per isolare il codice sotto test, e importante per scrivere test focalizzati e controllati evitando la fragilità dell'over-mocking, una competenza fondamentale per lo unit testing efficace.