Blog
Para quem já sabe o básico e quer ir fundo. Aqui o assunto é como os modelos funcionam em produção: memória, roteamento, ferramentas, agentes. O lado técnico que pouca gente explica direito.
Pirâmide clássica (Mike Cohn): muitos unit, alguns integration, poucos e2e. Trophy (Kent C. Dodds): integration como maioria. Diamond pra backend-heavy. Como escolher baseado em onde bugs realmente aparecem.
TDD clássico (red-green-refactor), outside-in TDD (London), BDD com cucumber. Onde ganha (design emergente, API clara), onde perde (exploração, UI complexa). Tom anti-dogma: TDD é ferramenta, não religião.
Vocabulário de Gerard Meszaros: Dummy (preenche slot), Stub (retorna canned), Fake (implementação simplificada — ex: in-memory DB), Mock (verifica interação), Spy (registra chamadas). Quando cada um — e quando você está mockando demais.
Exemplo baseado (tradicional) testa casos que você pensou. Property-based gera INPUTS aleatórios seguindo specs, testa invariantes. fast-check (JS/TS) e Hypothesis (Python). Shrinking: quando falha, reduz ao input mínimo que quebra.
Coverage 100% não significa testes bons. Mutation testing muta código (ex: troca + por -, remove ifs) e roda testes; se ainda passam, teste é fraco. Stryker (JS/TS), PIT (Java). Cost: lento — rode em CI nightly, não em PR.
Integration (módulos reais + DB real em test-container), Contract (consumer-provider via Pact), e2e (Playwright, Cypress — navega UI real). Trade-offs de velocidade vs confiança vs estabilidade. Matar "e2e flaky" virou prioridade em 2026.
Load (carga esperada), stress (até quebrar), soak (24h+), spike (rajada). k6 em TS como código, artillery YAML-simples. Perf budgets: p99 < 500ms é regressão. Run em CI staging antes de prod.
Projeto: pegar app real (próprio ou open source) e montar test harness completo — unit com vitest, integration com test-containers, contract com Pact, e2e Playwright, mutation Stryker nightly, k6 em pre-prod. CI orquestra paralelo com cache inteligente.