Por que testar o código

O custo de testar na mão

Imagine uma função que calcula o preço com desconto de um produto. Você a escreve, roda o programa, digita alguns valores e confere na tela se o resultado bate. Deu certo. No dia seguinte você muda um detalhe do cálculo, para tratar um novo caso. E agora? Você digita os mesmos valores de novo, um por um, e confere tudo outra vez na mão. Mudou mais uma coisa? Repete tudo mais uma vez. Cada mudança cobra o preço de refazer toda a conferência manual, e é justamente aí que a preguiça vence: você acaba conferindo só o caso que mexeu e torce para o resto continuar de pé.

Esse é o custo escondido de testar na mão. Não é o primeiro teste que pesa, é a repetição. Um programa de verdade tem dezenas de comportamentos, e conferir todos a cada alteração é inviável. O resultado é conhecido: o programador muda uma parte, quebra outra sem perceber, e o erro só aparece depois, quando alguém usa. Quanto mais tarde o erro aparece, mais caro ele fica para achar e corrigir.

A confiança para mudar o código

O ganho mais importante dos testes não é caçar erros, é a liberdade que eles dão. Quando um conjunto de testes cobre o seu código, você pode reescrever uma função para deixá-la mais clara, mudar um cálculo, reorganizar um módulo inteiro, e então rodar os testes. Se todos passarem, você tem uma garantia forte de que não quebrou nada do que estava coberto. Sem testes, cada mudança é uma aposta; com testes, vira uma verificação. Não é à toa que refatorar, que você viu no primeiro módulo, anda de mãos dadas com testar.

Nem tudo precisa de teste, e exagerar também tem custo. Um script que você roda uma vez para renomear arquivos e joga fora talvez não valha o esforço. Já uma função de cálculo, uma regra que decide algo importante ou um trecho que vários lugares usam, esses merecem testes, porque vão ser mudados muitas vezes ao longo da vida do programa. A pergunta prática é: se isto quebrar sem eu perceber, dói? Se a resposta for sim, escreva um teste. O curso segue nessa direção nas próximas aulas, do comando mais simples até uma suíte de testes organizada.

Há ainda um efeito colateral bom. Código difícil de testar costuma ser código mal organizado. Quando uma função faz coisas demais, mistura cálculo com leitura de tela e depende de mil detalhes externos, escrever um teste para ela vira um sofrimento. Isso é um sinal. Ao tentar testar, você é empurrado a separar responsabilidades, a fazer funções que recebem valores e devolvem resultados, exatamente o jeito pythônico que o curso vem defendendo. Testar melhora o desenho do programa, não só a sua segurança.

Fixando a ideia

Antes de seguir para o comando que sustenta todos os testes, vale fechar o raciocínio desta aula. Testar na mão não é errado, é apenas caro de repetir, e a repetição é o que quebra programas com o tempo. Automatizar um teste é escrever, uma vez, o mesmo que você faria com os olhos: dar uma entrada conhecida e conferir a saída. A diferença é que essa conferência passa a rodar em um segundo, sempre, sem depender da sua paciência.