Eu já fui daquele time que olhava para testes automatizados como se fossem um bicho de sete cabeças. Na primeira vez que tentei implementar, passei mais tempo debugando o teste do que o código que ele supostamente deveria testar. Morri de novo, e a culpa não foi do framework.
Implementar testes automatizados do zero é como aprender a cozinhar: você vai queimar o arroz algumas vezes, mas depois descobre que o segredo está em começar com algo simples e ir ajustando. Este guia é para quem está no ponto zero, sem suite de testes, sem pipeline, só com o desejo genuíno de parar de quebrar produção em plena sexta-feira.
Passo 1: Defina o que testar primeiro (e o que ignorar)
O erro mais comum de quem começa é querer testar tudo de uma vez. Não faça isso. Você vai se frustrar, o chefe vai reclamar do tempo perdido, e os testes vão virar uma dívida técnica ambulante.
Pegue a funcionalidade que mais quebra, aquela que o PO chama de "crítica" e o suporte chama de "aquela tela do demo". Escreva um teste unitário para a regra de negócio mais simples dela. Exemplo: se é um sistema de e-commerce, teste o cálculo de frete com um CEP válido. Só isso.
Dica de sobrevivência: Use a técnica do "teste do caminho feliz" primeiro. Depois você adiciona os casos de borda. Se tentar cobrir erro de digitação, timeout de API e buraco negro no banco na primeira leva, você desiste.
Passo 2: Escolha a ferramenta certa para sua stack
Não invente moda. Se seu projeto é Node.js, use Jest. Se é Python, pytest. Se é Java, JUnit. A ferramenta precisa ser a que a comunidade usa, não a mais bonita, não a que promete 10x mais performance, a que tem tutorial no YouTube em português.
Erro comum: baixar um framework hypado que ninguém do time conhece. Você vai passar o primeiro mês explicando sintaxe em vez de testar. Escolha algo que seu colega do lado também saiba ler.
Exemplo prático: No meu projeto React, usei Jest + Testing Library. Em dois dias, já tinha três testes rodando. Não precisei de curso de 40 horas.
Passo 3: Configure o ambiente de teste
Instale a ferramenta, crie uma pasta __tests__ ou tests/ na raiz do projeto, e configure o arquivo de configuração (ex.: jest.config.js). Rode o comando npm test e veja se aparece "no tests found", se aparecer, você está no caminho certo.
Dica prática: Adicione um script no package.json que rode os testes com --watch durante o desenvolvimento. Assim você vê na hora se quebrou algo.
Erro que já cometi: Esquecer de configurar o transform para JSX/TypeScript. O teste falhava dizendo "unexpected token" e eu culpei o framework. Era só um babel-jest esquecido.
Passo 4: Escreva seu primeiro teste de verdade
Crie um arquivo soma.test.js com uma função simples de soma. Teste se soma(2, 2) retorna 4. Rode. Se passar, você oficialmente implementou testes automatizados. Se falhar, verifique se a função está sendo exportada corretamente, 90% das falhas iniciais são erro de import/export.
Exemplo:
// math.js export function soma(a, b) { return a + b; }
// math.test.js import { soma } from './math';
test('soma 2 + 2 é igual a 4', () => { expect(soma(2, 2)).toBe(4); });
Ressalva: Não caia na armadilha de testar bibliotecas de terceiros. Teste SEU código. O Axios já foi testado por quem fez ele.
Passo 5: Integre os testes ao pipeline de CI
Sem integração contínua, seus testes são só enfeite. Configure o GitHub Actions, GitLab CI ou Jenkins para rodar npm test a cada push. Se o teste falhar, o pipeline quebra, e ninguém faz merge.
Dica de ouro: Comece com uma esteira simples: build -> test -> (opcional) lint. Depois de um mês funcionando, adicione cobertura mínima (ex.: 60%). Não coloque barreira alta no começo, senão ninguém consegue passar.
Erro comum: Configurar o CI para rodar os testes mas ignorar o resultado. Já vi pipeline verde com teste falhando porque ninguém configurou o exit code.
Passo 6: Mantenha os testes como prioridade (não como peso)
Teste automatizado não é tarefa de fim de sprint. É hábito. A cada bug corrigido, escreva um teste que impeça ele de voltar. A cada nova funcionalidade, escreva o teste antes (ou logo depois) do código.
Dica prática: Use o --coverage uma vez por semana para ver onde está descobrindo. Não precisa ser 100%, 70% bem escrito já segura as pontas.
Ressalva: Se o teste começar a demorar mais de 10 minutos para rodar, é sinal de que você está testando integração onde deveria testar unidade. Separe os testes lentos em uma suite à parte.
Checklist do que você fez
- [ ] Definiu a funcionalidade crítica para começar
- [ ] Escolheu uma ferramenta compatível com a stack
- [ ] Configurou o ambiente e rodou o primeiro teste
- [ ] Escreveu um teste unitário que passa
- [ ] Integrou os testes ao pipeline de CI
- [ ] Criou o hábito de testar antes de mergear
Perguntas frequentes sobre implementar testes automatizados
Qual a diferença entre teste unitário e teste de integração?
Teste unitário verifica uma função ou método isolado, sem dependências externas. Teste de integração verifica se dois ou mais componentes funcionam juntos (ex.: API + banco de dados). Comece pelos unitários, são mais rápidos e fáceis de escrever.
Preciso testar o front-end também?
Sim, mas não teste o layout pixel a pixel. Teste interações do usuário: clicar num botão abre o modal certo? Submeter um formulário com dados inválidos mostra erro? Use ferramentas como Testing Library ou Cypress para simular o comportamento real.
Quanto tempo leva para implementar testes do zero?
Depende do tamanho do projeto. Em uma semana, você tem os primeiros 10 testes rodando no CI. Em um mês, a suite já cobre as funcionalidades principais. O segredo é não parar, teste um pouquinho todo dia.
Devo testar o banco de dados?
Teste a camada de acesso a dados com um banco de teste em memória (ex.: SQLite para testes). Não use o banco de produção nem de staging. E lembre-se: teste a lógica de consulta, não o SQL em si.
E se meu time não quiser adotar testes?
Mostre o valor com dados. Antes de implementar testes, registre quantos bugs foram abertos no mês. Depois de um mês com testes, compare. Números não mentem, e seu chefe vai adorar ver a curva caindo.
Testes automatizados substituem o QA manual?
Não. Testes automatizados pegam regressão e casos repetitivos. QA manual pega usabilidade, fluxos inesperados e a sensação de "isso aqui está estranho". Um não vive sem o outro.