Cobertura de código com testes em Swift: como medir e melhorar a qualidade

Cobertura de código com testes em Swift: de "apenas testes" à confiança real

Você já removeu código "morto" e, uma semana depois, a compilação falhou? Ou se orgulhou de 90% de cobertura, mas os bugs ainda apareciam em produção? Se sim, este artigo é para você. A cobertura de código com testes (code coverage) em Swift não é apenas uma marca para CI/CD. É o seu radar pessoal: mostra quais partes do código são realmente testadas e quais vivem "na base da confiança".

Não vamos falar que escrever testes é necessário — isso é óbvio. Em vez disso, vamos analisar: como fazer o Xcode calcular a cobertura corretamente, quais métricas são realmente importantes (spoiler: não apenas a porcentagem) e por que 100% de cobertura é frequentemente uma armadilha. Vamos lá!

1. Por que medir a cobertura de código em Swift?

Imagine que você é o capitão de um navio e os testes são seus navegadores. A cobertura de código é um mapa que marca as áreas "exploradas". Se o mapa está em branco, você está navegando às cegas. Se está 100% preenchido, mas sem considerar casos extremos, você ainda corre o risco de encalhar.

Principais motivos para implementar code coverage Swift:

• Encontrar "zonas cinzas" — você vê imediatamente qual código nunca é executado nos testes (por exemplo, manipuladores de erro).
• Refatoração sem medo — uma alta métrica de cobertura dá luz verde para reescrever módulos.
• Documentação de requisitos — os testes se tornam documentação viva, e a cobertura mostra o quão completa essa documentação é.
• Controle de qualidade no CI — é possível proibir o merge se a cobertura cair abaixo de um limite (por exemplo, 80%).

Mas lembre-se do principal: cobertura de código com testes Swift é uma métrica, não um objetivo. Correr atrás de números por causa dos números é o caminho para testes inúteis que verificam getters e setters.

2. Ferramentas para medir cobertura em Swift: do Xcode a utilitários de terceiros

O ecossistema Swift oferece várias maneiras de obter as tão desejadas porcentagens. Vamos considerar três principais: o Xcode integrado, o utilitário slather e serviços de CI (por exemplo, Codecov).

2.1. Xcode Code Coverage integrado

A ferramenta mais simples e acessível. Tudo o que você precisa fazer é ativar a opção Gather coverage data no esquema de compilação (Product → Scheme → Edit Scheme → Test → Options). Após executar os testes, abra o Report Navigator (Cmd+9) e selecione a aba Coverage.

Vantagens: não requer instalação, integração com Xcode, mostra a cobertura em tempo real.

Desvantagens: não consegue combinar resultados de vários targets, difícil de exportar para CI.

Exemplo de configuração para o projeto:

// No esquema de compilação (Test → Options) marque "Code Coverage"// Após executar os testes (Cmd+U), veja o relatório no Report Navigator.// Para cada arquivo, você vê uma linha com a porcentagem de cobertura e linhas destacadas:// verdes — executadas, vermelhas — não executadas.

2.2. Slather — gerador de relatórios flexível

Slather é um utilitário open-source que analisa arquivos .profdata (resultados de cobertura do Xcode) e gera relatórios HTML bonitos, XML (Cobertura) ou até JSON. É especialmente útil se você usa CI e deseja manter um histórico de cobertura.

Instalação via CocoaPods ou Homebrew:

# Homebrewbrew install slather

# CocoaPods (no Podfile)pod 'slather'

Exemplo de configuração .slather.yml:

# .slather.ymlcoverage_service: cobertura_xmlxcodeproj: MyApp.xcodeprojscheme: MyAppsource_directory: MyApp/Sourcesoutput_directory: reportsignore:  - MyAppTests/*  - Pods/*

Execução:

slather coverage -s --scheme MyApp MyApp.xcodeproj

Vantagens: flexibilidade, suporte a diferentes formatos, integração com CI.

Desvantagens: