parametrize e testar exceções

Um teste, muitos casos

Imagine testar uma função que verifica se um número é par. Você quer conferir vários casos: pares, ímpares, zero, negativos. Escrever uma função de teste para cada seria repetitivo, e a repetição é inimiga da manutenção. O parametrize resolve isso com elegância. Você escreve o teste uma vez e fornece uma lista de entradas com os resultados esperados. O pytest roda a função uma vez para cada conjunto, e cada um aparece no relatório como um caso separado, com seus próprios valores.

import pytest

def eh_par(n):
    return n % 2 == 0

@pytest.mark.parametrize("entrada, esperado", [
    (2, True),
    (3, False),
    (0, True),
    (-4, True),
    (-7, False),
])
def test_eh_par(entrada, esperado):
    assert eh_par(entrada) == esperado

Cinco casos, uma função. Cada tupla vira um teste independente no relatório.

Os ganhos são concretos. Se um caso falha, o pytest diz exatamente qual conjunto de dados quebrou, sem confusão. Acrescentar um novo caso é adicionar uma linha à lista, não copiar uma função inteira. E a intenção fica cristalina: a tabela de entradas e saídas esperadas funciona quase como uma documentação do comportamento da função. Esse é o padrão certo sempre que você percebe que está prestes a copiar e colar um teste só mudando os números.

Testar que o erro certo acontece

Testar o caminho de sucesso é metade do trabalho. Um código robusto também levanta erros de propósito quando recebe algo inválido, e isso precisa ser testado. Não faz sentido deixar a exceção explodir e derrubar o teste; você quer justamente afirmar que ela aconteceu. Para isso existe o pytest.raises, usado com with. Você coloca dentro do bloco a chamada que deveria falhar e diz qual exceção espera. Se ela ocorre, o teste passa; se não, o teste falha, porque o erro esperado não veio.

import pytest

def raiz_quadrada(x):
    if x < 0:
        raise ValueError("nao existe raiz real de numero negativo")
    return x ** 0.5

def test_raiz_de_numero_valido():
    assert raiz_quadrada(9) == 3.0

def test_raiz_de_negativo_levanta():
    with pytest.raises(ValueError):
        raiz_quadrada(-1)

def test_raiz_de_negativo_mensagem():
    # match verifica um trecho da mensagem, alem do tipo.
    with pytest.raises(ValueError, match="numero negativo"):
        raiz_quadrada(-4)

with pytest.raises afirma que a exceção acontece; match confere a mensagem.

O parâmetro match, no último teste, acrescenta rigor. Ele verifica que a mensagem da exceção contém o trecho indicado, além de checar o tipo. Isso protege contra um engano sutil: o código levantar a exceção certa pelo motivo errado. Testar a mensagem confirma que a falha é aquela que você esperava. Junto com o parametrize, o pytest.raises fecha o ciclo de cobertura: você testa o que deve funcionar e também o que deve falhar, que é onde muitos bugs se escondem.

Cobrir os casos de borda

Reunindo os dois recursos, você consegue cobrir com poucos linhas o que importa numa função: os valores típicos, os limites e os inválidos. Casos de borda são onde os defeitos moram, o zero, o vazio, o negativo, o valor máximo, e o parametrize deixa listá-los sem esforço. As entradas inválidas, que devem levantar erro, entram com pytest.raises. Uma função bem testada tem essas três frentes cobertas, e o relatório verde passa a significar algo de verdade.

Um lembrete de bom senso: cobrir não é testar toda combinação imaginável, é escolher os casos que representam classes de comportamento. Para uma faixa de 0 a 100, você não testa os 101 valores; testa um valor no meio, os extremos 0 e 100, e o que fica logo fora da faixa para conferir o erro. Poucos casos bem escolhidos cobrem muito. Essa mentalidade, aliada ao parametrize e ao pytest.raises, produz suítes enxutas que ainda assim pegam o que precisa ser pego.