Testando casos de borda

Onde moram os bugs

Escrever um teste que passa é fácil quando você só testa o caso para o qual pensou a função. Uma função de média com a lista [2, 4, 6] devolve 4, o teste passa, e dá aquela sensação de dever cumprido. O problema é que o usuário real, ou o resto do programa, não manda só listas bem comportadas. Uma hora chega uma lista vazia, e a sua função tenta dividir por zero e explode. É nas bordas, nos limites do que a função aceita, que os bugs se escondem. Testar só o caminho feliz é como conferir se um carro anda em linha reta e nunca testar a curva.

Existe um pequeno repertório de bordas que vale checar em quase toda função. Se ela recebe uma coleção, teste com a coleção vazia e com um único elemento. Se recebe números, teste o zero, um negativo e, quando houver, o maior valor permitido. Se trabalha com posições, teste o primeiro e o último item, onde erros de um a mais ou um a menos costumam aparecer. Se há um limite, como maior de idade a partir de 18, teste 17, 18 e 19, os valores em torno da fronteira. Essa lista curta pega uma fatia enorme dos bugs reais.

import unittest


def media(valores):
    if not valores:
        raise ValueError("lista vazia nao tem media")
    return sum(valores) / len(valores)


class TestMedia(unittest.TestCase):
    def test_caso_normal(self):
        self.assertEqual(media([2, 4, 6]), 4)

    def test_um_elemento(self):
        self.assertEqual(media([10]), 10)

    def test_com_negativos(self):
        self.assertEqual(media([-2, 2]), 0)

    def test_lista_vazia_levanta_erro(self):
        with self.assertRaises(ValueError):
            media([])

Caso normal, borda de um elemento, negativos e a entrada inválida (lista vazia).

Testando entradas inválidas

Repare no último teste do exemplo. Uma lista vazia não é apenas uma borda, é uma entrada inválida: não faz sentido tirar a média de nada. A função foi escrita para reagir a isso levantando um ValueError, como você viu no módulo de exceções. E o teste verifica justamente esse comportamento com self.assertRaises. Ele diz espero que o bloco abaixo levante um ValueError. Se levantar, o teste passa; se a função não levantar nada, ou levantar outro erro, o teste falha. Testar o erro esperado é tão importante quanto testar o resultado certo.

# No pytest, o mesmo teste de excecao fica assim:
import pytest


def test_lista_vazia_levanta_erro():
    with pytest.raises(ValueError):
        media([])

# python -m pytest -> passa se media([]) levantar ValueError.

A versão pytest usa pytest.raises, com a mesma ideia do assertRaises do unittest.

Ao testar entradas inválidas, o objetivo não é fazer a função aceitar qualquer coisa, e sim garantir que ela falha de um jeito previsto e claro, em vez de devolver um resultado errado em silêncio ou estourar um erro confuso. Um programa confiável é aquele que se recusa a fazer o que não faz sentido, e faz isso de forma explícita. O teste registra essa promessa: se um dia alguém remover a checagem da lista vazia, o teste test_lista_vazia_levanta_erro falha e avisa que a proteção sumiu.

Um teste por comportamento

Repare que, no exemplo da média, cada teste verifica um comportamento e tem um nome que o descreve: test_caso_normal, test_um_elemento, test_com_negativos, test_lista_vazia_levanta_erro. Essa é a regra de ouro. Resista à tentação de espremer cinco verificações diferentes dentro de um único método só porque tratam da mesma função. Quando um teste cobre um só comportamento, uma falha aponta com precisão o que quebrou, e o nome do teste já conta a história antes mesmo de você olhar o código. Quando um teste gigante mistura tudo, uma falha diz apenas que algo naquele bolo deu errado, e você volta a caçar na mão, justamente o que os testes vieram evitar. Nomes claros e testes pequenos transformam a suíte em uma lista legível do que o seu código promete fazer.