testing

---
name: testing
description: >
  Estratégia e escrita de testes production-grade: pirâmide vs troféu, unit/integration/e2e, o que
  testar (comportamento, não implementação), test doubles, contract e mutation testing, cobertura
  útil. Use quando o usuário mencionar: "como testar", "escrever testes", "estratégia de testes",
  "cobertura", "test plan", "TDD", "mock vs stub", "teste e2e", "teste de integração", "flaky test".
---

# Testing

Você atua como engenheiro que trata testes como parte do design, não como imposto. Objetivo: testes que **dão confiança para mudar o código** — rápidos, determinísticos e focados em comportamento observável.

## Princípio central: teste comportamento, não implementação

Um teste bom falha quando o **comportamento** quebra e sobrevive a refatoração interna. Se mudar o "como" (sem mudar o "o quê") quebra o teste, ele testa a coisa errada.

## Qual formato — troféu > pirâmide (para a maioria dos apps)

```
      /\        e2e        poucos, caros, lentos — fluxos críticos ponta a ponta
     /  \
    /----\   integration   MUITOS — onde vive a confiança real (módulos + I/O reais/próximos)
   /------\
  /--------\    unit        muitos — lógica pura, ramos, edge cases
 /----------\  static      grátis — types, lint, format (pega classe inteira de bugs)
```

- **Static** (TypeScript, lint) elimina bugs sem escrever teste — use ao máximo.
- **Integration** dá o melhor retorno de confiança por esforço na maioria dos backends/UI.
- **e2e** só para os poucos fluxos que, se quebrarem, é incidente (login, checkout).

## O que testar

| Priorize | Despriorize |
|---|---|
| Regras de negócio e edge cases | Getters/setters triviais |
| Fronteiras (0, 1, N, vazio, nulo, limite) | Código de framework |
| Caminhos de erro e falha | 100% de cobertura como meta |
| Contratos entre módulos/serviços | Detalhes de implementação privada |

## Test doubles (use o nome certo)

- **Stub** — respostas prontas para input (controla o "vindo de").
- **Mock** — verifica interação (que foi chamado como esperado).
- **Fake** — implementação leve real (ex: DB em memória).
- **Spy** — registra chamadas sem alterar comportamento.
Regra: prefira **fakes reais** a mocks; mock demais = teste acoplado à implementação.

## Testes que valem a pena

- **Determinísticos** — sem relógio real, sem rede real não controlada, sem ordem dependente. Flaky test é dívida que corrói confiança → conserte ou delete.
- **Rápidos** — suíte de unit/integration em segundos; se dói rodar, ninguém roda.
- **Isolados** — cada teste monta e derruba seu estado.
- **AAA** — Arrange, Act, Assert; uma asserção lógica por teste.
- **Nome descreve o comportamento** — `deve rejeitar saque acima do saldo`.

## Técnicas avançadas (quando compensa)

- **Contract testing** (Pact) — garante que serviços que se integram concordam no contrato sem e2e caro.
- **Property-based** (fast-check/Hypothesis) — gera centenas de inputs; ótimo para lógica pura/parsing.
- **Mutation testing** (Stryker/PIT) — mede se seus testes *pegam bugs*, não só cobertura de linha.
- **Snapshot** — útil para output estável (UI/serialização); revise diffs, não aprove cego.

## Fluxo

1. Defina o comportamento observável a garantir.
2. Escolha o nível mais barato que dá a confiança (static → unit → integration → e2e).
3. Escreva o teste (TDD: antes do código quando o design está incerto).
4. Cubra edge cases e caminhos de erro.
5. Rode; garanta determinismo; mate flakiness.

## Recursos externos

| Recurso | O que pegar |
|---|---|
| [Testing Trophy (Kent C. Dodds)](https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications) | Por que integration > unit para apps. |
| [Testing Library](https://testing-library.com/) | Testar UI pelo comportamento do usuário, não por implementação. |
| [Playwright](https://playwright.dev/) | e2e moderno, confiável, com auto-wait (menos flaky). |
| [Martin Fowler — Test Double / Mocks aren't Stubs](https://martinfowler.com/articles/mocksArentStubs.html) | Vocabulário correto de doubles. |
| [Google Testing Blog](https://testing.googleblog.com/) | Práticas de escala (small/medium/large, flakiness). |
| [Pact (contract testing)](https://docs.pact.io/) | Contratos consumer-driven entre serviços. |

## Do / Don't

| Do | Don't |
|---|---|
| Testar comportamento observável | Testar detalhe interno |
| Fakes reais | Mock de tudo |
| Consertar/deletar flaky | Conviver com flaky |
| Cobrir edge cases e erros | Perseguir 100% de linha |

## Checklist

- [ ] Comportamento (não implementação) sendo verificado
- [ ] Nível escolhido é o mais barato que dá confiança
- [ ] Edge cases e caminhos de erro cobertos
- [ ] Testes determinísticos e isolados (zero flaky)
- [ ] Nomes descrevem comportamento
- [ ] Static analysis (types/lint) ligada ao máximo