Quais são os anti-padrões de testes comuns a evitar?

Question

Accepted Answer

Mesmo com as melhores intenções, equipes caem em **anti-padrões de testes** — práticas que tornam os testes frágeis, lentos, não confiáveis ou de baixo valor. Reconhecer e evitá-los é importante para manter uma suite de testes saudável e valiosa.

## Qualidade de testes anti-padrões

```text
✗ TESTING IMPLEMENTATION DETAILS → tests coupled to internals → break on every refactor
  (brittle) → test BEHAVIOR/outcomes instead
✗ FLAKY tests → intermittent failures erode trust → people ignore failures (real ones too)
✗ OVER-MOCKING → mocking everything → tests verify mock interactions, not real behavior;
  brittle and give false confidence
✗ Tests with NO meaningful assertions → run code but verify nothing (false coverage)
✗ GIANT tests checking many things → unclear what failed; hard to maintain
```

## Anti-padrões estruturais e estratégicos

```text
✗ ICE CREAM CONE → mostly slow E2E/manual, few unit tests → slow, brittle, expensive suite
✗ INTERDEPENDENT tests / shared mutable state → order-dependent, flaky, fragile
✗ Testing the FRAMEWORK / trivial code → low value; testing what doesn't need testing
✗ Chasing COVERAGE numbers → low-value tests written just to hit a percentage
✗ Slow tests → discourage running them → defeats fast-feedback value
```

## Anti-padrões de processo

```text
✗ Writing tests as an afterthought (or never) → poor coverage, untestable design
✗ Ignoring failing/flaky tests → the suite becomes untrusted/useless
✗ Not maintaining tests (test code rot) → tests are code; they need care
→ Recognize these and steer toward: behavior-focused, isolated, fast, meaningful,
  pyramid-shaped, maintained tests.
```

## Por que isso importa

Compreender anti-padrões de testes é conhecimento valioso em nível sênior porque **reconhecer e evitar práticas ruins de testes é essencial para manter uma suite de testes saudável e valiosa**, e esses anti-padrões são comuns mesmo com as melhores intenções, portanto é conhecimento prático importante.

Testes que caem em anti-padrões se tornam um passivo em vez de um ativo, então saber o que evitar é tão importante quanto saber o que fazer.

Compreender os **anti-padrões de qualidade de testes** — testes de detalhes de implementação (causando testes frágeis que quebram em refatorações), **testes instáveis** (erosão da confiança para que falhas sejam ignoradas), **excesso de mocking** (verificação de interações mock em vez de comportamento real, dando falsa confiança), testes sem assertions significativas (cobertura falsa) e testes gigantes e desfocos — ajuda a reconhecer e evitar as práticas que tornam testes individuais de baixo valor ou contraproducentes.

Compreender os **anti-padrões estruturais e estratégicos** — a **pirâmide invertida** (principalmente testes E2E/manuais lentos, produzindo uma suite lenta, frágil e cara), testes interdependentes, testes de código trivial ou do framework, **perseguição de números de cobertura** (escrever testes de baixo valor para atingir uma meta) e testes lentos (desestimulando sua execução) — ajuda a evitar uma suite de testes mal estruturada e ineficiente.

Compreender os **anti-padrões de processo** — escrever testes como um pensamento posterior (ou nunca), **ignorar testes falhando/instáveis** (tornando a suite não confiável e inútil) e não manter código de testes (deixar apodrecer) — ajuda a manter um processo de testes saudável.

Reconhecer esses anti-padrões e se orientar para seus opostos (testes focados em comportamento, isolados, rápidos, significativos, em forma de pirâmide, mantidos) é o que mantém uma suite de testes valiosa ao longo do tempo.

Como anti-padrões de testes são comuns (mesmo com as melhores intenções) e transformam testes de um ativo em um passivo (frágil, instável, lento, não confiável, de baixo valor), e como reconhecer e evitá-los é essencial para manter uma suite de testes saudável e valiosa, compreender anti-padrões de testes é conhecimento valioso em nível sênior — importante para manter os testes eficazes, refletindo a experiência para reconhecer e evitar os erros comuns que prejudicam as suites de testes e uma competência chave para engenheiros sêniors que orientam práticas de testes e mantêm a saúde das suites de testes ao longo do tempo.