¿Qué son los mocks, stubs y test doubles?

Question

Accepted Answer

**Test doubles** son objetos que reemplazan dependencias reales en las pruebas — incluyendo **mocks**, **stubs**, **spies**, **fakes** y **dummies**. Aíslan el código bajo prueba de sus dependencias (bases de datos, APIs, servicios), permitiendo pruebas unitarias rápidas, enfocadas y controladas.

## Por qué es 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)
```

## Los tipos de 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 (la distinción clave)

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

## Por qué importa

Entender los test doubles (mocks, stubs, etc.) es importante porque son **esenciales para escribir pruebas unitarias aisladas**, por lo que es un conocimiento de prueba valioso y frecuentemente aplicado.

Para probar una unidad de forma aislada (el objetivo de las pruebas unitarias), debes reemplazar sus dependencias reales (bases de datos, APIs, servicios) con **test doubles** — permitiendo pruebas que sean **rápidas** (sin I/O real), **controladas** (configurando escenarios exactos incluyendo condiciones de error que son difíciles de desencadenar con dependencias reales) y **deterministas** (sin problemas de flakiness externo).

Entender los **tipos** y sus propósitos es necesario: **stubs** (proporcionando respuestas predefinidas para controlar lo que las dependencias devuelven — alimentando la unidad con datos específicos), **mocks** (stubs que también verifican interacciones — comprobando que la unidad llamó a una dependencia correctamente), **spies** (registrando llamadas en objetos reales o falsos), **fakes** (implementaciones simplificadas funcionales como bases de datos en memoria) y **dummies** (placeholders).

Entender la **distinción clave mock-vs-stub** — los stubs controlan entradas (verificación de estado: proporcionando datos) mientras que los mocks verifican salidas/interacciones (verificación de comportamiento: comprobando que la unidad llamó correctamente a las dependencias) — es un conocimiento conceptual importante frecuentemente confundido, y usar cada uno apropiadamente importa.

Entender el **pitfall del over-mocking** (el excessive mocking acopla las pruebas a detalles de implementación, haciéndolas frágiles, por lo que deberías hacer mock en los límites correctos) refleja un juicio de prueba maduro.

Los test doubles se usan constantemente en pruebas unitarias para aislar el código bajo prueba.

Ya que las pruebas unitarias aisladas requieren reemplazar dependencias reales con test doubles (por velocidad, control y determinismo), y ya que entender los tipos, la distinción mock-vs-stub y el pitfall del over-mocking es necesario para escribir pruebas aisladas buenas, entender los test doubles es un conocimiento de prueba valioso y frecuentemente aplicado — esencial para pruebas unitarias, usado constantemente para aislar código bajo prueba e importante para escribir pruebas enfocadas y controladas mientras se evita la fragilidad del over-mocking, una habilidad central para pruebas unitarias efectivas.