Cobertura e TDD na prática

Medir a cobertura

Depois de escrever testes, uma pergunta natural surge: será que eles cobrem tudo que importa? A cobertura de testes responde a uma parte disso. Uma ferramenta de cobertura roda a sua suíte e observa quais linhas do código foram executadas e quais não foram. O relatório aponta os trechos que nenhum teste alcançou, os seus pontos cegos. No mundo Python, isso é feito com o pacote coverage, e o plugin pytest-cov integra a medição diretamente ao comando do pytest.

# No terminal:
#   pip install pytest-cov
#   pytest --cov=calculadora
#
# Saida (resumida):
#   Name             Stmts   Miss  Cover   Missing
#   ----------------------------------------------
#   calculadora.py      12      2    83%   18-19
#
# Leitura: 83% das linhas foram executadas pelos testes;
# as linhas 18-19 nunca rodaram (um ponto cego a investigar).

pytest --cov mede a cobertura; a coluna Missing aponta as linhas nunca testadas.

A leitura mais valiosa do relatório não é a porcentagem, é a coluna das linhas faltantes. Ela mostra, com precisão, qual ramo do seu código nunca foi exercitado, talvez um except que você nunca testou ou um caminho de erro esquecido. Esse é o uso saudável da cobertura: um radar de pontos cegos. Você olha as linhas não cobertas, decide se elas merecem teste e escreve o que faltar. É uma conversa com o seu código sobre o que ainda não foi verificado.

O que a cobertura não garante

Aqui mora a armadilha mais comum. Cobertura mede se uma linha foi executada, não se ela foi testada de forma útil. É perfeitamente possível ter 100% de cobertura com testes ruins, que rodam todas as linhas mas quase não fazem asserções, ou que não checam os casos de borda que interessam. A porcentagem vira um número mágico enganoso quando alguém persegue os 100% por si mesmos, escrevendo testes vazios só para colorir o relatório de verde. Isso é gastar esforço sem ganhar confiança.

O jeito equilibrado é usar a cobertura como diagnóstico, não como meta. Cobertura baixa em uma parte importante do código é um alerta legítimo: ali falta teste. Mas a qualidade do teste vem das asserções certas sobre os comportamentos certos, incluindo os casos de borda e de erro das aulas anteriores. Uma suíte com 80% de cobertura e asserções afiadas vale mais que uma com 100% de testes ocos. Meça a cobertura para achar buracos, e preencha-os com testes que de fato verificam algo.

TDD: escrever o teste antes

O TDD inverte a ordem que parece natural: você escreve o teste antes do código que ele testa. O ciclo tem três passos, muitas vezes lembrados pelas cores. No red, você escreve um teste para um comportamento que ainda não existe, e ele falha, como deve. No green, você escreve o mínimo de código para o teste passar, sem se preocupar com elegância. No refactor, com o teste verde te dando segurança, você melhora o código, sabendo que se quebrar algo o teste avisa na hora. Depois, repete para o próximo comportamento.

# TDD para uma funcao que soma so os numeros pares de uma lista.

# 1) RED: escreva o teste primeiro. Ele falha (a funcao nem existe).
def test_soma_pares():
    assert soma_pares([1, 2, 3, 4]) == 6   # 2 + 4
    assert soma_pares([]) == 0
    assert soma_pares([1, 3, 5]) == 0

# 2) GREEN: o minimo para passar.
def soma_pares(numeros):
    return sum(n for n in numeros if n % 2 == 0)

# 3) REFACTOR: o codigo ja esta limpo; se nao estivesse,
# voce melhoraria agora, com o teste verde protegendo.

O ciclo TDD: teste que falha, código mínimo que passa, refino com rede de segurança.

O TDD não é obrigatório, mas traz benefícios que valem experimentar. Escrever o teste antes força você a pensar no contrato da função, o que entra e o que sai, antes de se perder na implementação. O resultado costuma ser um código mais testável e com interfaces mais claras, além de uma cobertura naturalmente alta e honesta, porque cada linha nasceu para satisfazer um teste real. Com este módulo, você fecha a frente de qualidade do curso: sabe escrever testes com pytest, organizá-los com fixtures, cobrir casos com parametrize, isolar dependências com mocks, medir cobertura e deixar os testes guiarem o desenho.