Como eu realmente escrevo testes primeiro com GitHub Copilot (sem mentir para mim mesmo)
O desenvolvimento orientado a testes falha porque escrever testes é mais lento do que escrever código. O Copilot inverte a matemática e é neste fluxo de trabalho que realmente funciona.
Todo desenvolvedor acredita em testes da mesma forma que todo mundo acredita no uso do fio dental, e o desenvolvimento do teste primeiro falha pelo mesmo motivo: quando você está no fluxo, escrever testes é como parar para resolver a papelada. O Copilot mudou a matemática para mim, não por tornar os testes agradáveis, mas por torná-los rápidos o suficiente para que a objeção à papelada desaparecesse. Este é o fluxo de trabalho onde ele realmente se mantém.
O truque é escrever o teste como uma especificação e deixar o Copilot fazer o padrão. Antes de abordar a implementação, escrevo um teste com falha com o cenário no nome do teste e um comentário descrevendo o comportamento esperado em linguagem simples. O Copilot preenche as afirmações, a simulação e a configuração com uma competência surpreendente, porque os arquivos de teste são exatamente o tipo de código padronizado em que ele se destaca. Meu trabalho se resume a revisar se o teste testa a coisa certa, o que é um julgamento, não uma digitação.
Agrupe os cenários, uma função por vez. Eu listo os casos antes de começar, o caminho feliz, a entrada vazia, o limite, o erro, depois faço o Copilot gerá-los em uma única passagem e revisar o conjunto juntos. A revisão de cinco testes como um conjunto detecta o que falta na revisão deles um por um: o caso ausente, geralmente aquele estranho pelo qual sua base de código foi mordida antes. Meu prompt pré-voo agora inclui uma linha de comentários listando incidentes de produção anteriores neste módulo, porque o modelo não pode conhecer esse contexto a menos que você o informe.
A parte honesta do teste primeiro com IA é saber onde ela engana. O Copilot terá prazer em escrever um teste que reflita suas suposições erradas, e um conjunto verde baseado em mal-entendidos compartilhados é pior do que nenhum conjunto, porque defende o bug. O antídoto é barato e inegociável: antes de implementar, execute o teste e observe-o falhar pelo motivo certo, depois quebre deliberadamente a saída esperada na afirmação e confirme se o teste a detecta. Trinta segundos por teste que mantém o conjunto honesto.
O que isso me rendeu na prática: cobertura nos caminhos chatos, validação de entradas e tratamento de erros, que eu nunca escrevia, porque o custo caiu para quase zero. O que isso não me comprou: uma desculpa para deixar de pensar sobre o que o código deveria fazer, que é onde o teste primeiro sempre deveria ajudar de qualquer maneira. O ritmo refatorador vermelho-verde sobrevive intacto; O Copilot acabou de remover a parte em que escrever o teste vermelho parecia um imposto.
