1.1 O que os testes compram

• Confiança para mudar: o valor nº 1. Uma suíte verde depois de um refactor te diz "não quebrei nada óbvio". Sem isso, a base de código "congela" — ninguém mexe com medo.
• Documentação executável: um bom teste mostra como usar a unidade e o que ela garante — e não fica desatualizado (se ficar, quebra).
• Feedback de design: código difícil de testar quase sempre é código mal desenhado (acoplado demais, fazendo coisas demais). O teste é um "primeiro cliente" que reclama.
• Rede de detecção: pegar a regressão no CI, não no cliente.
• O que testes NÃO fazem: não provam ausência de bugs ("testes mostram a presença, não a ausência" — Dijkstra); não substituem revisão de código nem tipos; e não valem nada se ninguém os roda ou se são flaky.

1.2 Os tipos de teste

1.3 A pirâmide e o troféu

A PIRÂMIDE (Mike Cohn)              O "TESTING TROPHY" (Kent C. Dodds)

        /\   E2E  (poucos)                 ___
       /  \                               /E2E\      poucos
      /----\  Integração (alguns)        /-----\
     /      \                           / Integ.\    MUITOS  ← o centro de gravidade
    /--------\ Unit (muitos, rápidos)  /---------\
                                       |  Unit   |  alguns
                                       |_________|
                                       (+ análise estática / tipos na base)

1.4 O que "testar como o usuário usa" significa

Um princípio que unifica testing moderno (frontend e backend): teste comportamento observável, não detalhes de implementação. "Ao clicar em Comprar com o carrinho vazio, aparece a mensagem X" > "o método validateCart chama isEmpty". O primeiro sobrevive a refactors; o segundo quebra a cada mudança interna e não prova nada de útil.

2.1 FIRST

2.2 Estrutura: AAA / Given-When-Then

test("cupom expirado não aplica desconto", () => {
  // ARRANGE (given): monta o cenário
  const carrinho = umCarrinho({ total: 100 });
  const cupom = umCupom({ percentual: 10, expiraEm: ontem() });

  // ACT (when): executa a ação sob teste
  const resultado = aplicarCupom(carrinho, cupom);

  // ASSERT (then): verifica o resultado observável
  expect(resultado.total).toBe(100);
  expect(resultado.erro).toBe("cupom_expirado");
});

• Um comportamento por teste (pode ter várias asserções sobre o mesmo resultado).
• Nome que documenta: "faz X quando Y" — quem lê o relatório de falha entende sem abrir o código.
• Sem lógica no teste (if/for/try) — se o teste precisa de lógica, ele pode ter bugs; prefira table-driven / parametrizado.
• Object mothers / builders (umCarrinho({...})) para montar dados de teste legíveis, com defaults sensatos e só o relevante explícito.

2.3 Test doubles

2.4 Determinismo

• Tempo: injetar um "clock" (ou usar fake timers) — nunca Date.now() real num teste.
• Aleatoriedade: semear o RNG, ou injetar a fonte de aleatoriedade.
• Ordem de iteração (maps/sets), fusos, locale — fixar.
• Rede / sistema de arquivos: substituir por fakes; se precisar de rede, é teste de integração, não unitário.

3.1 O ciclo

 ┌──────────────────────────────────────────────────┐
 │  1. RED    — escreva um teste que falha           │
 │             (define o comportamento que você quer) │
 │  2. GREEN  — escreva o MÍNIMO de código para passar│
 │             (nem elegante, nem geral — só passar)  │
 │  3. REFACTOR — melhore o design com a rede verde   │
 │             (sem mudar comportamento; testes cobrem)│
 └──────────────► repita (ciclos de minutos) ◄────────┘

3.2 As duas escolas

Na prática, a maioria dos times usa uma mistura pragmática: outside-in para explorar o design de uma feature, classicist para a maior parte dos testes de unidade (mais estáveis).

3.3 Test-first × test-after

• Test-first (TDD): o teste guia o design; você não escreve código "não pedido"; menos over-engineering.
• Test-after: aceitável e comum; o risco é escrever testes que "confirmam o que o código já faz" (inclusive os bugs) e testar a implementação em vez do comportamento.
• Meio-termo útil: escrever o teste logo depois de um pequeno trecho, ainda com a intenção fresca, e usá-lo para dirigir o próximo trecho.

3.4 Quando TDD ajuda e quando atrapalha

3.5 O mito da cobertura de 100%

Cobertura de linha mede o que foi executado, não o que foi verificado. Você pode ter 100% de cobertura com testes que não têm asserção nenhuma. É útil como detector de partes não testadas (cobertura baixa é sinal de alerta), mas péssimo como meta (leva a testes-teatro que inflam o número). Melhor sinal de qualidade da suíte: mutation testing (Módulo 6) e o escape rate de bugs (Módulo 9).

4.1 O problema do "integrado mas mockado"

Se você mocka o banco, a fila e todo serviço externo, seus "testes de integração" testam a sua mocagem, não a integração. Bugs reais moram exatamente nas fronteiras: um JOIN errado, um mapeamento de coluna, um timezone, um formato de data, uma constraint, um limite de payload, o comportamento de "linha não encontrada". Mock nenhum pega isso.

4.2 Testcontainers

Testcontainers (bibliotecas para Java, Go, .NET, Node, Python…) sobe a dependência real em um contêiner Docker efêmero durante o teste — um Postgres de verdade, um Redis, um Kafka, um LocalStack para AWS — e o derruba ao fim. Você ganha realismo (o SQL roda no mesmo motor da produção) sem manter infra de teste compartilhada (que sempre driftou e ninguém confia).

// esboço (Node/Vitest + Testcontainers)
let pg;
beforeAll(async () => {
  pg = await new PostgreSqlContainer("postgres:16").start();
  await migrate(pg.getConnectionUri());
});
afterAll(() => pg.stop());

test("salva e recupera um pedido, preservando o timezone", async () => {
  const repo = new PedidoRepo(pg.getConnectionUri());
  const criado = await repo.save(umPedido({ criadoEm: "2026-08-30T14:00:00Z" }));
  const lido = await repo.findById(criado.id);
  expect(lido.criadoEm.toISOString()).toBe("2026-08-30T14:00:00.000Z");
});

• Cada suíte (ou cada teste, se rápido) com um contêiner limpo, ou TRUNCATE entre testes — isolamento.
• Mais lento que unit (segundos), então: rodar em paralelo, e num estágio de CI separado do test:unit rápido.

4.3 Contract testing

Testar dois serviços rodando juntos em E2E é lento e frágil. Contract testing verifica a interface entre eles sem isso:

• Consumer-driven contracts (Pact): o consumidor define o que espera da API do provedor (nas suas requisições/respostas) e gera um contrato; o provedor roda esse contrato contra a sua implementação real no CI. Se o provedor quebrar a API, o build dele falha — antes de o consumidor perceber em produção.
• Schema-based: o provedor publica um OpenAPI/Protobuf; ferramentas (Schemathesis, Dredd, Pactflow, oasdiff) validam que a implementação bate com o schema e que mudanças não são breaking (ver apostila de API Design).
• Onde fica: entre o teste de integração e o E2E. Barato, rápido, e resolve o problema real ("os dois times evoluem sem falar e a API quebra").

5.1 O papel do E2E

• Cobre: os fluxos de negócio críticos ponta a ponta (login, checkout, criar-e-publicar), integração real de todas as peças, e a "cola" que os testes menores não veem.
• Não cobre: casos de borda (isso é unit), validações de formulário exaustivas, cada permutação — colocá-las no E2E gera uma suíte lenta e frágil.
• Quantidade: dezenas, não milhares. Cada E2E deve poder ser justificado por "se este quebrar, é um incidente".

5.2 Playwright

Playwright (Microsoft) virou o padrão de E2E web moderno. Diferenciais:

test("usuário completa o checkout", async ({ page, loginComoCliente }) => {
  await loginComoCliente();                 // fixture
  await page.goto("/produtos/cafe-especial");
  await page.getByRole("button", { name: "Adicionar ao carrinho" }).click();
  await page.getByRole("link", { name: "Finalizar compra" }).click();
  await page.getByLabel("Cartão").fill("4242 4242 4242 4242");
  await page.getByRole("button", { name: "Pagar" }).click();
  await expect(page.getByText("Pedido confirmado")).toBeVisible();   // re-tenta até timeout
});

5.3 Flakiness — a doença do E2E

Um teste flaky passa e falha sem mudança de código. Um pouco de flakiness corrói toda a confiança na suíte ("ah, é flaky, roda de novo") e esconde bugs reais.

Gestão de flaky (Módulo 9): detecção automática (rodar N vezes), quarentena (isola do gate, mas continua rodando e reportando), dashboard de flakiness, e prazo para consertar ou deletar. retries mascaram — use com parcimônia e sempre com visibilidade.

5.4 Playwright × Cypress × Selenium

• Playwright: multi-browser real (inclui WebKit), auto-wait robusto, paralelização nativa, trace viewer, API testing, multi-linguagem (TS/JS, Python, .NET, Java). O default recomendado hoje.
• Cypress: ótima DX e time-travel debugger; historicamente limitado a Chromium-family e a um domínio por teste (melhorou); roda no browser.
• Selenium / WebDriver: o padrão histórico (WebDriver é um padrão W3C); mais verboso, sem auto-wait embutido, mas amplíssimo suporte de linguagem/browser e ecossistema (Grid). Ainda comum em empresas grandes.

6.1 Property-based testing

Em vez de escrever exemplos ("somar(2,3) === 5"), você declara propriedades que valem para qualquer entrada, e a ferramenta gera centenas de casos aleatórios (incluindo bordas: 0, negativos, muito grande, string vazia, unicode) tentando quebrar a propriedade.

// fast-check (JS) — propriedades de uma função de serialização
test("round-trip: parse(serialize(x)) === x", () => {
  fc.assert(fc.property(fc.record({ nome: fc.string(), idade: fc.nat() }), (x) => {
    expect(parse(serialize(x))).toEqual(x);
  }));
});

• Propriedades típicas: round-trip (encode/decode), invariantes (ordenar não muda o tamanho nem o conjunto de elementos), idempotência (f(f(x)) === f(x)), comutatividade/associatividade, comparação com um oráculo (uma implementação lenta mas óbvia).
• Shrinking: quando encontra uma falha, a ferramenta reduz o caso ao mínimo que ainda quebra ("falha com [1, -2147483648]" em vez de um array de 300 números) — o bug fica óbvio.
• Ferramentas: Hypothesis (Python), fast-check (JS/TS), jqwik (Java), proptest/quickcheck (Rust), PropEr/StreamData (Erlang/Elixir).
• Ideal para: parsers, serialização, algoritmos, lógica com muitos casos, matemática, validação.

6.2 Fuzzing

Alimentar a função/programa com entradas malformadas, aleatórias ou geradas por cobertura em massa, procurando crashes, hangs, panics, vazamentos de memória. Diferença para property-based: fuzzing foca em robustez (não quebrar feio) mais que em correção, e roda por horas/contínuo. Ferramentas: libFuzzer/AFL++ (C/C++/Rust via cargo-fuzz), go test -fuzz (nativo em Go), Jazzer (JVM), Atheris (Python). Essencial para código que processa entrada não confiável (parsers de formato, protocolos, decoders — cruza com a apostila de Cibersegurança).

6.3 Mutation testing "quem testa os testes?"

Cobertura diz o que foi executado. Mutation testing diz o que foi verificado: a ferramenta introduz pequenos bugs no código de produção ("mutantes" — troca > por >=, + por -, remove uma linha, inverte um if) e roda a suíte. Se algum teste falha, o mutante foi "morto" (bom — a suíte pega esse tipo de erro). Se todos passam, o mutante "sobreviveu" — há um buraco na suíte naquele ponto.

• Mutation score = % de mutantes mortos. É um indicador de qualidade da suíte muito melhor que cobertura de linha.
• Ferramentas: Stryker (JS/TS/C#/Scala), PIT/pitest (Java), mutmut/cosmic-ray (Python), go-mutesting (Go).
• É caro (roda a suíte N vezes) — rodar sobre o diff de um PR ou periodicamente, não a cada commit.

6.4 Snapshot e approval testing (com cuidado)

• Snapshot testing: a primeira execução grava a saída ("snapshot"); execuções seguintes comparam. Ótimo para saídas grandes e estáveis (um objeto complexo, uma resposta de API). Perigo: quando o snapshot quebra, é tentador só "atualizar" sem olhar — e você acabou de gravar o bug como "esperado". Regra: snapshots pequenos e legíveis, revisados a sério na atualização, e nunca de coisas que mudam legitimamente toda hora.
• Approval / golden testing: versão mais deliberada — a saída "aprovada" fica num arquivo versionado; a mudança é um diff explícito no PR que alguém aprova. Bom para geradores de código, formatadores, relatórios.

7.1 Performance e carga

• Ferramentas: k6 (scripts em JS, ótimo para CI), Gatling (Scala/Java DSL), Locust (Python), JMeter (clássico), Vegeta.
• Sempre medir percentis (p95/p99), não média; definir o critério de aprovação como um threshold (p95 < 400ms E taxa de erro < 1%) — o teste falha o build se estourar.
• Testar contra um ambiente parecido com produção (dados, escala) — carga num ambiente de brinquedo não diz nada.

7.2 Acessibilidade automatizada

Ferramentas como axe-core (via @axe-core/playwright, jest-axe, Lighthouse) pegam automaticamente ~30–50% dos problemas de acessibilidade (contraste, alt ausente, labels de formulário, ordem de headings, ARIA inválido) — rode em cada página no CI. Os outros ~50–70% exigem teste manual e com tecnologia assistiva. Detalhe completo na apostila de Acessibilidade digital & WCAG.

7.3 Regressão visual

Captura screenshots de componentes/páginas e compara pixel a pixel (com tolerância) contra uma baseline aprovada — pega quebras de layout, CSS, e mudanças não intencionais que testes funcionais não veem. Ferramentas: Playwright toHaveScreenshot(), Percy, Chromatic (para Storybook), Applitools (com IA para reduzir falsos positivos). Cuidado com flakiness de renderização (fontes, antialiasing, animações — desabilitar) e com baselines que ninguém revisa.

7.4 Segurança no pipeline

• SAST (análise estática — Semgrep, CodeQL, SonarQube): padrões de código inseguro.
• SCA / dependências (Dependabot, Snyk, npm audit, OWASP Dependency-Check, govulncheck): CVEs em libs.
• DAST (OWASP ZAP): ataca a app rodando.
• Secret scanning (gitleaks, trufflehog): credencial commitada.
• Testes de autorização negativa: um usuário tentando acessar o recurso de outro deve dar 403 (ver apostila de API Design — BOLA).
• Detalhe na apostila de Cibersegurança Prática & DevSecOps e na de Segurança de Aplicações de IA.

7.5 Resiliência

Chaos engineering (injetar falhas: matar instâncias, adicionar latência, particionar rede) e game days validam que a resiliência projetada (timeouts, retries, circuit breakers, fallbacks — ver apostilas de Arquitetura e de SRE) realmente funciona antes do incidente real.

8.1 IA para escrever e manter testes

8.2 Testar sistemas que contêm IA

Quando o sistema sob teste usa um LLM ou um modelo de ML, o teste tradicional (entrada → saída exata) quebra: a saída é texto aberto e não determinístico. As abordagens (detalhe completo na apostila de LLMOps & Avaliação):

• Separe o que é determinístico: a maior parte do sistema (parsing, roteamento, chamada de ferramenta, formatação, guardrails, retries) é testável de forma clássica. Isole a chamada ao modelo atrás de uma interface e teste o resto com um stub.
• Assertions parciais / baseadas em propriedade: em vez de "a resposta é exatamente X", verifique "a resposta contém o número da política", "é JSON válido no schema", "não menciona a concorrência", "cita uma fonte", "tem menos de N tokens". São asserções determinísticas sobre uma saída não determinística.
• Datasets de avaliação (evals) + LLM-as-judge: um conjunto de casos com rubricas, julgados por um modelo calibrado contra humanos, rodando no CI como gate ("o score agregado não caiu > 2 pontos vs baseline"). Isso é a suíte de "testes" de um sistema de IA.
• Repetição para lidar com variância: rodar cada caso N vezes e exigir maioria; olhar o score agregado (estável) em vez de exigir 100% caso a caso; temperatura 0 nos testes.
• Testes adversariais: prompt injection, jailbreak, PII na saída (ver apostila de Segurança de Aplicações de IA).
• Regressão de modelo do provedor: a mesma suíte de evals rodando periodicamente pega quando o modelo por trás da API mudou e regrediu — algo que teste de código nunca pega.

9.1 Design para testabilidade

• Injeção de dependências e ports & adapters / hexagonal (ver apostila de Arquitetura): o domínio puro testa sem infra; as fronteiras (banco, rede, relógio, filesystem) são interfaces substituíveis.
• Funções puras onde possível — entrada → saída, sem efeito colateral — são triviais de testar.
• Separar decisão de ação ("functional core, imperative shell"): a lógica que decide é pura e testada exaustivamente; a casca que faz (I/O) é fina e testada por integração.
• Ganchos de teste explícitos: data-testid no frontend, endpoints de seed/reset num ambiente de teste, feature flags.
• Se algo é difícil de testar, a resposta quase nunca é "escreva um teste feio" — é "refatore para ser testável".

9.2 Gestão de dados de teste

9.3 Gestão de testes flaky

• Detecção: rodar a suíte (ou os testes alterados) N vezes; um teste com resultado inconsistente é marcado. Ferramentas de CI modernas (e serviços como CircleCI/BuildKite/Datadog CI Visibility) fazem isso.
• Quarentena: o teste flaky é removido do gate (não bloqueia o merge) mas continua rodando e reportando, com um dono e um prazo. Não é "delete e esquece".
• Dashboard de flakiness: taxa por teste, tendência, top ofensores. Trata-se como bug de prioridade.
• retries: mascaram a flakiness. Aceitáveis em E2E com visibilidade (o relatório mostra "passou na 2ª tentativa"), nunca como forma de "resolver" — um teste que só passa no retry esconde um bug (na app ou no teste).
• Orçamento de flakiness: acima de X% a suíte perde a confiança do time; priorizar a redução como se fosse um incidente.

9.4 Shift-left e shift-right

• Shift-left: testar cedo — tipos e lint na IDE, testes no commit, contract tests no PR, segurança no CI. Quanto mais cedo o bug é pego, mais barato.
• Shift-right / testing in production: algumas verificações só são reais em produção — canary (comparar SLIs da nova versão vs baseline), feature flags (ligar para 1% e observar), synthetic monitoring (rodar um E2E contra produção a cada minuto), A/B e observabilidade como "teste contínuo". Não substitui shift-left — complementa. Ver apostila de Observabilidade & SRE.

9.5 CI de testes em escala

• Estágios por velocidade: lint + typecheck + unit (segundos, em todo push) → integração (minutos, testcontainers) → E2E (paralelizado/sharded) → não-funcionais (nightly ou pré-deploy).
• Paralelização e sharding (Playwright --shard, Jest/Vitest --shard, split por tempo histórico).
• Test impact analysis / seleção de testes: rodar só os testes afetados pelo diff (Nx, Bazel, Vitest --changed, ferramentas comerciais) — corta o tempo de CI drasticamente em monorepos.
• Cache de dependências, de build, de imagens Docker.
• Fail fast vs run all: fail-fast no PR (feedback rápido); run-all no merge para o relatório completo.

9.6 A estratégia de teste como documento

Um time maduro tem uma test strategy escrita (1–2 páginas): o que se testa em cada camada, o que não se testa e por quê, os padrões (nomes, fixtures, doubles), o orçamento de flakiness, quem é dono de quê, e as métricas. Métricas úteis: escape rate (bugs que chegaram a produção / total), lead time do CI, flakiness rate, mutation score em módulos críticos. Cobertura de linha: um sinal secundário, nunca uma meta contratual.

10.1 Os perfis que contratam

10.2 Roadmap de estudo (7–9 semanas)

10.3 Banco de perguntas de entrevista (com a resposta que aprova)

10.4 Projetos de portfólio que geram entrevista

1. Suíte completa de um projeto real (âncora): uma app pequena com pirâmide bem distribuída — unit (sem mockar demais), integração com Testcontainers, um contract test, E2E com Playwright (fixtures, zero waitForTimeout, trace no CI), e um gate não-funcional (k6 + axe). README com a test strategy escrita.
2. Estudo de mutation testing: pegar um módulo com "boa cobertura", rodar Stryker/PIT, mostrar os mutantes sobreviventes e os testes que você adicionou para matá-los.
3. Property-based num parser/algoritmo: as propriedades, o shrinking encontrando um caso mínimo, e o bug que ele revelou.
4. Anti-flakiness: pegar uma suíte E2E flaky (real ou plantada), documentar as causas e as correções, com o "antes/depois" da taxa.
5. Eval de uma feature de IA: um dataset + LLM-as-judge + gate no CI para uma pequena feature que usa um LLM (cruza com a apostila de LLMOps).

10.5 Fontes para continuar

• Fundamentos: Unit Testing Principles, Practices, and Patterns (Vladimir Khorikov) — a referência sobre o que faz um bom teste; Growing Object-Oriented Software, Guided by Tests (Freeman & Pryce) — o clássico de TDD outside-in; Working Effectively with Legacy Code (Michael Feathers).
• Prático: a documentação do Playwright (excelente); os artigos de Kent C. Dodds (testing trophy, "testing library"); o material de Testcontainers e de Pact.
• Estratégia: os escritos de Martin Fowler sobre testing (Test Pyramid, "Mocks Aren't Stubs", "Unit Test"), e o "Google Testing Blog".
• Property-based: a doc da Hypothesis (mesmo que você use outra linguagem — a filosofia está lá).