Como Testar Código Legado Sem Precisar Reescrever Tudo

O problema

Código legado assusta porque costuma vir junto com o combo completo:

• acoplamento ruim
• nome ruim
• dependência demais
• efeitos colaterais espalhados
• ninguém muito seguro sobre o que pode quebrar

A reação comum é uma destas:

• “não dá para testar isso”
• “antes precisamos refatorar tudo”

As duas travam.

Porque, enquanto o time discute a melhor abordagem possível, o código continua sem proteção nenhuma.

Modelo mental

Pense assim:

testar legado não é um projeto para arrumar a arquitetura inteira. É um jeito de comprar confiança incremental no código que você já tem.

Isso muda bastante o começo.

Você não precisa esperar:

• design ficar bonito
• dependência ficar perfeita
• módulo virar exemplo de livro

Você precisa só encontrar um lugar onde um teste útil cabe agora.

Quebrando o problema

Comece pelo que mais dói mexer

A melhor pergunta inicial quase nunca é:

“Qual arquivo está mais feio?”

Melhor perguntar:

“Qual parte quebra com frequência, assusta o time ou tem impacto real quando erra?”

É ali que o primeiro teste costuma render mais.

Teste de caracterização é um começo honesto

Às vezes você ainda nem sabe qual deveria ser o comportamento ideal.

Mas consegue registrar o comportamento atual.

Esse é o papel do teste de caracterização:

• documentar o que o sistema faz hoje
• reduzir medo antes da mudança
• permitir refatorar sem voar às cegas

Ele não resolve tudo.

Mas já transforma “acho que era assim” em algo observável.

Procure uma costura pequena

Código legado gigante geralmente não aceita um teste bonito logo de cara.

Mas quase sempre existe um ponto menor onde você consegue entrar:

• uma função com retorno claro
• um endpoint específico
• um caso de uso muito repetido
• uma regra de cálculo

Essa costura pequena costuma render mais do que tentar cobrir o módulo inteiro.

Refatorar um pouco para testar pode ser válido

Tem uma nuance importante aqui.

“Não preciso reescrever tudo” não significa “não posso tocar em nada”.

Às vezes faz sentido:

• extrair uma função
• separar um efeito colateral
• isolar uma regra

desde que isso esteja a serviço de ganhar teste logo, e não de iniciar uma limpeza sem fim.

Não tente pagar toda a dívida técnica com a desculpa do teste

Esse erro acontece muito.

A tarefa era:

• adicionar proteção antes de mudar um fluxo

Mas vira:

• reorganizar pastas
• renomear metade do módulo
• trocar padrão
• redesenhar arquitetura

E o teste mesmo não chega.

O projeto fica elegante no discurso e fraco no resultado.

Exemplo simples

Imagine um módulo antigo de cálculo de comissão com 600 linhas e um monte de if.

O time precisa mudar uma regra de bônus.

Plano ruim:

1. refatorar o módulo inteiro
2. depois pensar em teste

Plano melhor:

1. capturar alguns cenários reais de entrada e saída
2. escrever testes de caracterização para esses casos
3. extrair só a parte da regra que precisa mudar
4. escrever testes novos para a regra alterada
5. mexer com mais segurança

Isso não deixa o código bonito de uma vez.

Mas já tira o time do escuro.

Erros comuns

• Adiar teste até o código “merecer”.
• Transformar uma mudança pontual em reescrita total.
• Tentar cobrir tudo antes de proteger o que mais dói.
• Ignorar teste de caracterização porque ele não parece elegante.
• Confundir “legado difícil” com “legado impossível”.

Como um senior pensa

Quem tem mais experiência costuma perguntar:

“Qual é o menor recorte que me dá confiança suficiente para mexer sem abrir um incidente?”

Essa pergunta é ótima para legado.

Ela puxa o trabalho para pragmatismo em vez de culpa técnica.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você sabe ganhar controle em ambiente imperfeito.

Você sobe de nível quando:

• não usa feiura do código como desculpa para desistir
• propõe teste incremental em vez de reescrita total
• cita teste de caracterização com critério
• mostra que entende risco, escopo e custo de mudança

Uma resposta forte costuma soar assim:

“Eu não esperaria o código legado ficar bonito para começar a testar. Eu escolheria o fluxo mais arriscado ou mais frequente, capturaria o comportamento atual com alguns testes de caracterização e criaria pequenas costuras para mexer com menos risco.”

Código legado não precisa pedir desculpa para ganhar teste.

Quando o time espera a hora perfeita para testar legado, continua pagando risco com juros.