Testes de caracterização em código legado registram o comportamento atual antes da mudança e ajudam a reduzir quebras inesperadas.
O problema: alterar código que ninguém explica
Código legado não é necessariamente código antigo: é código cuja alteração parece arriscada porque regras, efeitos colaterais e dependências não estão claros. Um método pode ter poucos anos e ainda ser legado se ninguém sabe quais comportamentos precisam ser preservados.
Nessa situação, reescrever ou refatorar primeiro costuma aumentar a incerteza. Antes de decidir como o código deveria funcionar, vale descobrir o que ele faz hoje para as entradas que importam. Testes de caracterização em código legado servem justamente para transformar esse comportamento observado em uma proteção verificável.
O objetivo não é provar que o sistema está correto do ponto de vista do negócio. É criar um ponto de partida: se uma mudança alterar uma saída, um efeito ou uma interação que antes existia, o teste sinaliza a diferença para que o time decida conscientemente se ela é desejada.
Como criar testes de caracterização em código legado?
Testes de caracterização em código legado registram o comportamento atual antes da mudança e ajudam a reduzir quebras inesperadas.
Comece por uma mudança pequena e concreta, como corrigir um cálculo, substituir uma dependência ou separar uma função extensa. Escolha o caminho diretamente relacionado à alteração em vez de tentar cobrir todo o módulo de uma vez.
Execute esse caminho com entradas representativas e registre o resultado observável: valor retornado, estado gravado, mensagem enviada ou exceção produzida. Em seguida, escreva um teste que reproduza a mesma entrada e verifique esse resultado. Só depois faça a alteração planejada.
Por exemplo, uma rotina de desconto pode devolver um total inesperado para um cupom vencido. Antes de corrigir a regra, crie casos com cupom válido, vencido, ausente e com valor no limite. O caso aparentemente estranho também merece registro se clientes, integrações ou telas já dependem dele.
O que observar além do valor retornado
Muitos comportamentos relevantes não aparecem no retorno de uma função. Uma chamada pode gravar dados, consultar outro serviço, emitir evento, registrar log ou lançar uma exceção específica. Teste aquilo que o restante do sistema consegue perceber.
Priorize quatro perguntas: qual entrada ativa o comportamento, qual saída é produzida, quais efeitos externos ocorrem e qual falha é esperada. Essa lista evita testes vagos que apenas executam linhas de código sem documentar uma regra.
Quando houver dependências lentas ou imprevisíveis, como banco de dados, relógio do sistema ou serviço remoto, substitua-as por implementações controladas no teste. A meta é isolar a regra sob investigação, não recriar toda a produção. Ainda assim, não simule detalhes que você não precisa verificar: mocks em excesso podem fazer o teste confirmar a própria implementação, e não o comportamento útil.
Quando o teste revela uma regra errada
Um teste de caracterização pode capturar um defeito já existente. Isso não o torna inútil; ele apenas documenta que a correção mudará o comportamento. Nesse caso, mantenha o teste antigo com um nome que explicite o cenário atual, acrescente um teste para a regra desejada e altere o código de forma deliberada.
A diferença é importante para revisão. Em vez de uma mudança que parece uma refatoração inofensiva, o conjunto de testes deixa claro que houve uma decisão de produto ou negócio. Se for possível, confirme a regra com quem conhece o domínio antes de remover a proteção anterior.
Evite converter todo comportamento estranho em requisito permanente. Testes de caracterização são uma rede temporária ou duradoura conforme o valor do fluxo, mas cada caso deve ter um nome que explique por que existe e pode ser revisado quando a regra ficar clara.
Uma sequência segura para refatorar depois
Com os testes passando, faça uma alteração por vez: extraia uma função, renomeie uma variável, remova duplicação ou troque uma dependência. Execute a suíte após cada passo. Mudanças pequenas tornam mais fácil localizar a causa quando algo falha.
Se não for possível testar uma área por depender de muitos recursos externos, procure um ponto de entrada menor. Às vezes basta extrair o cálculo puro de um controlador ou encapsular acesso a arquivo e rede atrás de uma interface simples. O primeiro ganho é reduzir o acoplamento que impede a observação.
A cobertura não será completa, e isso é um limite normal. O critério prático é proteger os caminhos que a mudança pode afetar e os cenários cujo erro tem maior impacto. Uma suíte pequena, rápida e confiável costuma ser mais útil do que centenas de testes frágeis.
Para ampliar a estratégia, o artigo Manutenção de Código Legado: Estratégias para Evoluir Sistemas aborda limites de mudança e entendimento gradual do sistema. Já Code review e refatoração: como melhorar a qualidade do código ajuda a transformar essas proteções em uma prática coletiva de revisão.
Quando testes de caracterização não bastam?
Eles não substituem validação de requisitos, testes de integração nem observação em produção. Um teste pode preservar uma saída conhecida e ainda deixar de detectar que o fluxo falha com dados reais, permissões diferentes ou concorrência.
Também não resolvem código impossível de executar localmente sem algum trabalho de preparação. Nesses casos, comece criando pontos de observação, separando dependências e registrando cenários críticos. A evolução pode ser gradual; exigir uma arquitetura ideal antes de qualquer teste normalmente adia a redução de risco.
Para mudanças que afetam consumidores externos, combine a técnica com contratos e testes automatizados. O artigo APIs e testes automatizados: como evoluir sistemas sem quebrar contratos mostra por que compatibilidade precisa ser tratada como parte da mudança, não como uma verificação posterior.
FAQ
Testes de caracterização substituem testes de integração? Não. Eles protegem comportamentos observados em uma área específica, enquanto testes de integração verificam a colaboração entre componentes reais ou próximos do real.
O que fazer quando um teste revela um comportamento incorreto? Registre o comportamento atual, crie um teste para a regra desejada e trate a mudança como correção deliberada. Assim, a equipe consegue revisar o impacto com clareza.
