O que são mocks, stubs e test doubles?

Question

Accepted Answer

**Test doubles** são objetos que substituem dependências reais em testes — incluindo **mocks**, **stubs**, **spies**, **fakes** e **dummies**. Eles isolam o código testado de suas dependências (bancos de dados, APIs, serviços), permitindo testes unitários rápidos, focados e controlados.

## Por que 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)
```

## Os 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 (a distinção-chave)

```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 que isso importa

Entender test doubles (mocks, stubs, etc.) é importante porque eles são **essenciais para escrever testes unitários isolados**, então é um conhecimento de testes valioso e frequentemente aplicado.

Para testar uma unidade isoladamente (o objetivo do teste unitário), você deve substituir suas dependências reais (bancos de dados, APIs, serviços) por **test doubles** — permitindo testes que são **rápidos** (sem E/S real), **controlados** (configurando cenários exatos, incluindo condições de erro que são difíceis de disparar com dependências reais) e **determinísticos** (sem instabilidade externa).

Entender os **tipos** e seus propósitos é necessário: **stubs** (fornecendo respostas canned para controlar o que as dependências retornam — alimentando a unidade com dados específicos), **mocks** (stubs que também verificam interações — verificando se a unidade chamou uma dependência corretamente), **spies** (registrando chamadas em objetos reais ou fake), **fakes** (implementações simplificadas funcionais como bancos de dados em memória) e **dummies** (placeholders).

Entender a **distinção-chave entre mock e stub** — stubs controlam entradas (verificação de estado: fornecendo dados) enquanto mocks verificam saídas/interações (verificação de comportamento: verificando se a unidade chamou dependências corretamente) — é um conhecimento conceitual importante frequentemente confundido, e usar cada um apropriadamente importa.

Entender o **armadilha de over-mocking** (mock excessivo acopla testes aos detalhes de implementação, tornando-os frágeis, então você deve fazer mock nos limites corretos) reflete julgamento maduro em testes.

Test doubles são usados constantemente em testes unitários para isolar o código testado.

Já que testes unitários isolados exigem substituir dependências reais por test doubles (para velocidade, controle e determinismo), e já que entender os tipos, a distinção mock-vs-stub e a armadilha de over-mocking é necessário para escrever bons testes isolados, entender test doubles é um conhecimento de testes valioso e frequentemente aplicado — essencial para testes unitários, usado constantemente para isolar código testado e importante para escrever testes focados e controlados evitando a fragilidade de over-mocking, uma habilidade central para testes unitários eficazes.