Ao escrever código de teste, chega um momento em que você começa a ficar obcecado pelo número da cobertura.
Eu entendo bem a sensação de pensar: “Já que estamos fazendo, vamos chegar a 100%.”
Indo direto ao ponto, uma cobertura de código na faixa de 70–80% é o alvo mais realista na prática, e 100% não significa código sem bugs. Vou explicar o motivo com base também na minha experiência.
Veja primeiro o resumo dos pontos principais
Para quem está com pressa, organizei primeiro a conclusão do artigo.
- 100% de cobertura significa apenas que “todas as linhas foram executadas”, não que “todos os casos foram verificados”.
- Na prática, a recomendação geralmente fica em torno de 70–80%.
- Para lógicas críticas, como pagamentos e autenticação, vale buscar 90% ou mais.
- É mais importante saber “o que não foi testado” do que olhar para o número.
100% de cobertura de código significa que não há bugs?
Esse é o equívoco mais comum.
100% de cobertura significa apenas que os testes “executaram todas as linhas do código pelo menos uma vez”.
Isso não significa que verificaram se cada linha funciona corretamente.
Vamos a um exemplo. Na função abaixo, o teste apenas executa o código, sem verificar corretamente o resultado.
func divide(_ a: Double, _ b: Double) -> Double {
return a / b // bse 0? O teste é executado, mas
}
// Este teste tem cobertura 100%, mas
@Test func divide_apenas executa_o código() {
_ = divide(10, 2) // não verifica o valor retornado(#expect)!
}Esse código atinge 100% de cobertura.
Mas, como não verifica o resultado usando #expect, na prática não garante nada.
A cobertura mede “quanto foi executado”, não “o quanto foi bem verificado”.
É por isso que não se deve confiar apenas no número.
Então, qual percentual é adequado?
Organizei em uma tabela o critério realista que percebi depois de passar por várias equipes. (Recomendação prática geral em 2026)
| Área do código | Cobertura recomendada | Motivo |
|---|---|---|
| Lógica de negócio principal | 90% ou mais | Falhas em pagamentos ou autenticação podem ser críticas |
| Código geral de serviços | 70~80% | Faixa com melhor relação entre custo e benefício |
| Camadas de UI e de visualização | 50~60% | Mudam com frequência e têm alto custo de manutenção dos testes |
| Arquivos gerados automaticamente e de configuração | Excluir da medição | Os testes têm pouco significado |
O Google também já declarou publicamente que considera internamente 60% “aceitável”, 75% “recomendado” e 90% “exemplar”.
Não existe uma resposta única, mas considere algo perto de 80% uma meta razoável para a maioria das equipes.
Por que insistir em 100% pode acabar sendo prejudicial?
O esforço para cobrir os 20% finais é muito maior do que o necessário para cobrir os 80% iniciais.
Testar todo o tratamento de exceções, as ramificações difíceis de alcançar e o código defensivo faz o tempo crescer exponencialmente.
Há um problema ainda maior.
Surgem “testes de fachada” criados apenas para completar o número.
Testes que aumentam a cobertura sem realmente verificar nada só atrapalham quando o código é alterado mais tarde.
A cada refatoração, você acaba gastando tempo corrigindo testes sem significado.
Perguntas frequentes (Q&A)
P. Então medir a cobertura não serve para nada?
Não. A cobertura é muito útil para encontrar áreas que os testes nunca alcançam.
Em vez de transformar o número em meta, use o relatório de cobertura para verificar as áreas vermelhas (código não executado).
P. Podemos impor um limite de cobertura no CI?
Pode, mas recomendo algo como “código novo com pelo menos 80%”.
Impor um limite alto de forma geral a todo o código desgasta a equipe por causa do código existente.
P. Parece haver vários tipos de cobertura?
Além da cobertura de linhas, vale observar também a cobertura de ramificações.
Verificar se ramificações condicionais como if/else foram devidamente testadas se aproxima mais da qualidade real.
Não se deixe pressionar pelo número; pergunte primeiro: “Este teste está realmente protegendo alguma coisa?”
Uma suíte de testes sólida com 80% de cobertura é muito mais confiável do que uma suíte vazia com 100%. Espero que você continue escrevendo ótimos testes hoje também!