Refatoração e testes assistidos

Com o contexto certo (módulo 1) em mãos, este módulo trata de onde aplicar isso primeiro. Entre os muitos usos possíveis de IA em código, refatoração e escrita de testes se destacam por uma razão específica: ambos têm alta verificabilidade — o mesmo eixo do curso de Fundamentos de IA sobre onde a IA ajuda de verdade.

Por que refatoração é um bom ponto de partida

Refatorar é mudar a estrutura interna do código sem mudar o comportamento observável. Isso dá uma vantagem rara: existe um critério objetivo e imediato de acerto — o comportamento antes e depois precisa ser idêntico, o que os testes existentes (se houver) confirmam na hora.

Isso reduz drasticamente o risco de usar IA aqui, comparado a pedir uma funcionalidade nova do zero: uma funcionalidade nova não tem "resposta certa" fixa para comparar, mas uma refatoração tem — o comportamento anterior é literalmente a especificação.

Onde IA ajuda bem em refatoração:

• Extrair código duplicado em uma função ou módulo compartilhado, quando o padrão duplicado já existe em vários lugares do projeto.
• Renomear e reorganizar para seguir uma convenção que o restante do projeto já usa — um caso claro de reformatar informação existente, do módulo sobre onde a IA ajuda em Fundamentos de IA.
• Simplificar uma estrutura complexa cujo comportamento você já entende bem o suficiente para reconhecer se a simplificação mudou algo.

Onde é mais arriscado: refatorações grandes, que tocam muitos arquivos de uma vez, ou refatorações em código sem cobertura de testes — sem testes, "o comportamento não mudou" vira uma alegação que ninguém consegue confirmar rápido.

Por que testes são o outro lado do mesmo argumento

Escrever testes tem uma verificabilidade diferente, mas igualmente alta: você já sabe o comportamento esperado do código (você é quem escreveu ou revisou), então avaliar se um teste gerado está correto é rápido — muito mais rápido do que escrever o teste do zero.

Um padrão útil, seguindo o módulo de prompts reutilizáveis do curso de IA para Produtividade: peça primeiro uma lista dos casos que deveriam ser testados (incluindo casos de borda), revise essa lista, e só depois peça a implementação de cada teste. Revisar a lista de casos é mais barato do que revisar testes já escritos que cobrem os casos errados.

O risco comum aos dois: teste ou refatoração que "passa" mas está errado

O risco central em ambos os usos não é a IA escrever código que não compila — isso é um erro visível, o sistema avisa. O risco é código que parece funcionar mas contém um erro sutil: um teste que valida o comportamento errado (porque foi escrito olhando para o código, não para a especificação real), ou uma refatoração que muda um comportamento em um caso de borda que os testes existentes não cobriam.

Isso é exatamente o padrão de "erro silencioso" do curso de Fundamentos de IA aplicado a código: sem verificação ativa, nada vai forçar a correção depois.

Como verificar sem perder o ganho de tempo

• Depois de uma refatoração, rode a suíte de testes completa, não só os que "parecem relacionados" — o objetivo é confirmar que nada mudou em nenhum lugar, não só onde você esperava.
• Ao revisar um teste gerado, pergunte: esse teste falharia se o código estivesse errado do jeito que eu mais me preocupo? Um teste que passaria mesmo com o bug mais provável presente não está protegendo o que deveria.
• Para refatorações em código sem cobertura de testes, considere escrever os testes básicos primeiro (usando o próprio assistente, com o método do módulo anterior) e só depois refatorar — invertendo a ordem para reduzir risco.

Exercício

Escolha um trecho do seu código com duplicação óbvia ou com pouca cobertura de teste. Aplique o fluxo deste módulo: se for refatorar, confirme que há testes cobrindo o comportamento atual primeiro; se for escrever testes, peça a lista de casos antes da implementação.

O que fica

• Refatoração e testes têm alta verificabilidade — existe um critério objetivo (comportamento preservado, caso testado corretamente) para julgar o resultado rápido.
• Refatoração é mais segura com cobertura de testes existente; sem ela, o "comportamento não mudou" não pode ser confirmado rápido.
• Peça a lista de casos de teste antes da implementação — revisar a lista é mais barato que revisar testes já escritos errados.
• O risco central não é erro visível (não compila) — é erro silencioso: teste que valida a coisa errada, refatoração que muda um caso de borda não coberto.