Você muda uma linha para corrigir um problema e, sem perceber, quebra outra parte do sistema. Só descobre dias depois, quando um usuário reclama. Os testes automatizados existem para evitar justamente isso: são uma rede de proteção que avisa na hora em que algo deixou de funcionar.
O que é um teste automatizado
É um trecho de código que chama o seu código com uma entrada conhecida e confere se a saída é a esperada. Em vez de abrir o programa, digitar valores e olhar a tela, você roda um comando e vê uma lista de aprovados e reprovados.
Imagine uma função que calcula o total de um pedido somando os itens e aplicando um desconto. Um teste diria: “para dois itens de 10 e 20, com 10% de desconto, o total deve ser 27”. Se algum dia a função devolver outro valor, o teste falha e mostra onde.
A estrutura quase sempre segue três passos:
- Preparar: criar os dados de entrada.
- Executar: chamar a função ou a parte do sistema.
- Conferir: comparar o resultado com o esperado, usando uma asserção (assert).
Os tipos mais comuns
Testes unitários
Verificam uma peça pequena e isolada, como uma função. São rápidos e baratos de escrever, e formam a maior parte dos testes de um projeto saudável. Respondem: “esta função faz o que deveria?”.
Testes de integração
Verificam se partes diferentes funcionam juntas, como o código e o banco de dados, ou o seu servidor e uma API. São mais lentos e mais complexos, mas pegam erros que os unitários não veem, como um nome de coluna errado.
Testes de ponta a ponta
Simulam o uso real, geralmente controlando um navegador: abrir a página, preencher o formulário, clicar no botão e conferir o resultado. Cobrem o fluxo completo, mas são os mais lentos e os mais frágeis, porque mudanças visuais podem quebrá-los.
Uma regra de bolso: muitos testes unitários, alguns de integração e poucos de ponta a ponta, só para os caminhos críticos, como cadastro e compra.
Ferramentas conhecidas
Cada linguagem tem as suas. Em Python, a biblioteca padrão traz o unittest, e a pytest é muito popular por ser simples. Em JavaScript, ferramentas como Jest e Vitest são comuns. Para ponta a ponta no navegador, existem ferramentas como Playwright e Cypress. Os nomes e as versões mudam; o conceito permanece.
Na maioria dos casos, você cria um arquivo de testes, escreve funções com nomes que começam com “test” e roda um único comando. Se você está começando em Python, Python para iniciantes: seus primeiros passos é o ponto de partida antes de testar.
Por que vale a pena
- Segurança para mudar. Você refatora e corrige com confiança, porque o teste avisa se algo quebrou.
- Bugs pegos cedo. Um erro encontrado em segundos é muito mais barato que um encontrado por um cliente.
- Documentação viva. Os testes mostram, com exemplos, como o código deve se comportar.
- Apoio ao trabalhar com IA. Quando um assistente de código altera arquivos, os testes ajudam a confirmar se nada se perdeu (veja como revisar código gerado por IA).
- Publicação mais tranquila. Muitas plataformas permitem rodar os testes antes de cada deploy e bloquear a publicação se algum falhar.
Quando não compensa tanto
Testes também têm custo: tempo para escrever e manutenção. Em um script descartável que você roda uma vez, ou em um protótipo que será jogado fora, o benefício é pequeno. O mesmo vale para testar detalhes visuais pequenos que mudam toda semana.
Como começar sem se sobrecarregar
- Escolha uma função com regra clara, como calcular um desconto, validar um CPF ou formatar uma data.
- Escreva um teste para o caso normal.
- Adicione casos de borda: valor zero, texto vazio, número negativo, lista sem itens.
- Quando encontrar um bug, escreva primeiro um teste que o reproduz. Corrija o código até o teste passar. Assim o mesmo erro não volta.
- Rode os testes antes de cada commit. O hábito pega bem com Git no dia a dia.
Testes na rotina de publicação
Os testes ficam ainda mais valiosos quando rodam sozinhos. Plataformas de código e de deploy permitem executar a bateria de testes a cada envio de código. É a chamada integração contínua: se algum teste falha, a publicação é barrada e você é avisado.
Para começar, basta uma regra: nada vai para a versão principal sem os testes passarem. Mesmo com poucos testes, isso cria disciplina. Com o tempo, cada bug resolvido ganha seu teste, e o conjunto vira um retrato do que o sistema precisa fazer. É um investimento que cresce junto com o projeto.
Um exemplo de bom primeiro teste
Escolha uma função pequena, como a que calcula desconto. Escreva um teste para um valor normal, outro para desconto zero e outro para um valor inválido, como negativo. Três testes de cinco linhas cada já protegem a regra mais importante e mostram, na prática, como o processo funciona.
O que os testes não fazem
Passar nos testes não prova que o programa está certo; prova que ele se comporta como os testes esperam. Testes não substituem usar o produto, ouvir usuários e revisar a segurança. Para ver como conferir a experiência real, veja teste de usabilidade de app.
Comece pequeno: três testes bem escolhidos já mudam a forma de mexer no código. Aumente a cobertura onde os erros doem mais, e use os testes como aliados, não como obrigação.