O que é cobertura de testes?

Question

Accepted Answer

**Cobertura de testes** mede quanto do código é **executado pelos testes** — tipicamente como uma porcentagem (ex: 80% de cobertura). É uma métrica útil para encontrar código não testado, mas é importante entender suas limitações: alta cobertura não garante bons testes.

## O que a cobertura mede

```text
TEST COVERAGE = the % of code exercised by the test suite:
  LINE coverage → % of code lines executed by tests
  BRANCH coverage → % of branches (if/else paths) taken
  FUNCTION coverage → % of functions called
  STATEMENT coverage → % of statements executed
→ Coverage tools instrument the code and report what tests do/don't exercise.
```

## Por que a cobertura é útil

```text
✓ FINDS UNTESTED code — low coverage areas reveal what lacks tests (a gap finder)
✓ A measurable quality signal; track it over time; many teams set a target (e.g. ≥80%)
✓ Highlights branches/paths/error cases that tests miss
```

## As limitações (importante!)

```text
⚠️ HIGH COVERAGE ≠ GOOD TESTS:
  → coverage shows code was EXECUTED, NOT that behavior was correctly VERIFIED
  → you can execute code with NO meaningful assertions → 100% coverage, tests verify nothing
  → 100% coverage can still miss bugs (untested input combinations, logic errors)
⚠️ Chasing a coverage NUMBER → writing low-value tests just to hit the target
→ Coverage is a USEFUL guide (find gaps), NOT a guarantee of quality. Use it wisely;
  focus on testing important behavior well, not just hitting a percentage.
```

## Por que isso importa

Entender cobertura de testes — incluindo suas limitações — é valioso porque é uma **métrica comumente usada** que é útil quando entendida corretamente, mas enganosa quando usada incorretamente, então é um conhecimento prático importante.

Cobertura mede **quanto código é executado pelos testes** (como uma porcentagem, via cobertura de linha, branch, função ou statement), e entendê-la é útil porque **encontra código não testado** (revelando lacunas onde os testes são insuficientes — uma forma valiosa de identificar o que precisa ser testado), fornece um sinal de qualidade mensurável que os times podem acompanhar, e destaca branches não testadas e casos de erro.

Muitos times usam cobertura como uma métrica de qualidade com metas.

No entanto, entender as **limitações é criticamente importante**: **alta cobertura não é igual a bons testes** — cobertura mostra que o código foi *executado*, não que seu comportamento foi corretamente *verificado*, então você pode ter alta cobertura (até mesmo 100%) com testes sem sentido (executar código sem assertions adequadas não verifica nada), e cobertura completa ainda pode deixar bugs passar (combinações de entrada não testadas, erros de lógica).

O perigo de **perseguir um número de cobertura** (escrever testes de baixo valor apenas para atingir uma meta) é um anti-padrão real.

Entender que **cobertura é um guia útil para encontrar lacunas, não uma garantia de qualidade** — e que o foco deve estar em testar comportamentos importantes bem, em vez de atingir uma porcentagem — reflete um julgamento maduro que evita o erro comum de tratar cobertura como o objetivo em vez de uma ferramenta.

Como cobertura é uma métrica amplamente usada que é genuinamente útil (encontrar código não testado) mas comumente mal entendida e usada incorretamente (tratada como garantia de qualidade ou uma meta a ser manipulada), e como entender tanto seu valor quanto suas limitações importantes permite usá-la com sabedoria, entender cobertura de testes é conhecimento valioso e praticamente relevante — uma métrica útil para entender corretamente, onde apreciar suas limitações (cobertura ≠ qualidade) é tão importante quanto a métrica em si, refletindo um sólido julgamento de testes.