Suíte de testes mínima para código gerado por IA que se mantém estável

Por que o código gerado por IA continua quebrando depois que você corrige\n\nCódigo gerado por IA costuma funcionar até você mexer. Você corrige um bug e duas telas não relacionadas quebram. Um deploy que funcionou ontem falha hoje. Pequenas mudanças causam surpresas porque o código tem efeitos colaterais escondidos e regras pouco claras.\n\nNa prática, costuma acontecer assim:\n\n- Uma alteração no login quebra o faturamento porque ambos dependem de um helper pela metade.\n- A estrutura de uma resposta de API muda e a UI cai silenciosamente em estados em branco.\n- A autenticação funciona localmente mas falha em produção por variáveis de ambiente faltando ou segredos vazados.\n- Um refactor rápido dispara falhas aleatórias porque o estado está guardado no lugar errado.\n\nIsso é comum em protótipos gerados por IA porque o código vem em pedaços, não pensado como um sistema. Nomes variam, hacks temporários viram dependências e raramente existe uma rede de segurança. Equipes acabam fazendo correções de emergência repetidas vezes. É caro e estressante.\n\nA forma mais barata de estancar o problema é uma suíte de testes pequena e de alto valor. Testes não são mágicos. Eles só detectam quebras cedo, antes que os usuários as vejam. Também dão confiança para refatorar e remover partes estranhas sem adivinhar.\n\nTrês tipos de teste dão a maior proteção pelo menor esforço:\n\n- Testes de smoke: a aplicação roda basicamente?\n- Testes de contrato de API: as respostas continuam compatíveis com a UI e integrações?\n- Testes de regressão: um bug corrigido permanece corrigido?\n\nO objetivo não é 100% de cobertura. O sucesso é mais simples: você consegue fazer deploy sem medo, mexer no código sem quebrar correções da semana passada e as falhas apontam para a funcionalidade específica que quebrou.\n\n## Escolha o que proteger primeiro (os 20% que causam 80% da dor)\n\nSe sua app foi gerada por ferramentas de IA, pode parecer que tudo é frágil. Uma suíte mínima funciona melhor quando protege os poucos caminhos que as pessoas usam todo dia, e os lugares onde uma pequena mudança pode quebrar cinco outras coisas.\n\nComece listando as jornadas de usuário que geram mais chamados de suporte quando falham. Seja prático: o que faria o produto parecer fora do ar para um usuário real? Normalmente é login e cadastro (incluindo reset de senha), checkout ou mudanças de assinatura, seu fluxo principal de criar-editar-deletar, webhooks e upload/download de arquivos.\n\nDepois, olhe para integrações que mais provavelmente vão quebrar de maneiras estranhas: pagamentos, envio de email, provedores de identidade e armazenamento de arquivos. Você não precisa de cobertura end-to-end completa. Quer verificações rápidas que provem que você ainda consegue conectar e obter uma resposta sensata.\n\nAgora escolha apenas 3 a 5 endpoints ou fluxos que nunca podem falhar. Para um SaaS simples, pode ser: login, criar projeto, convidar colega, cancelar assinatura.\n\nAntes de escrever um teste, defina o que “funcionar” significa para cada um. Mantenha a definição curta e mensurável:\n\n- Código de status esperado e um ou dois campos chave\n- Forma da resposta (chaves e tipos)\n- Um efeito colateral importante (registro criado, email enfileirado, webhook enviado)\n- Uma regra de segurança chave (não acessar dados de outros usuários)\n\nFinalmente, escolha um ambiente de teste e mantenha-o. Local é aceitável se a configuração for consistente. Staging é aceitável se os dados forem controlados. Misturar ambos vira ruído confuso e deixa de ser “mínimo”.\n\n## Testes de smoke: cheques rápidos que pegam quebras óbvias\n\nSmoke tests respondem a uma pergunta depois de qualquer mudança: a app ainda sobe, e os caminhos mais importantes respondem?\n\nUm bom smoke test não tenta provar que tudo está correto. Prova que o básico não está totalmente quebrado. Por isso smoke tests são uma ótima primeira camada para projetos escritos por IA.\n\n### O que incluir\n\nEscolha alguns alvos que representem “a app está viva” e “usuários conseguem fazer o principal”. Por exemplo:\n\n- Um health check retorna 200 (ou a página inicial carrega)\n- A página de login é renderizada (ou o endpoint de auth responde)\n- Uma chamada API central retorna o status esperado (como buscar o usuário atual ou uma lista principal)\n- A conexão com o banco pode ser aberta (só se isso falhar com frequência)\n\nMantenha cada teste curto. Mire em uma asserção clara por teste, como “retorna 200” ou “a resposta inclui userId”. Quando um smoke test falha, você quer que o motivo seja óbvio.\n\n### Como mantê-los rápidos e confiáveis\n\nDefina um limite rígido: menos de 1 a 2 minutos no total. Smoke tests devem rodar constantemente, não “quando alguém lembra”. Uma rotina simples funciona bem:\n\n- Rode os smoke tests localmente antes de enviar\n- Rode automaticamente em cada pull request\n- Bloqueie merges se falharem\n\nExemplo: você consertou um fluxo de auth que retornava 500 aleatoriamente. Adicione um smoke test que faça login com uma conta de teste e depois chame GET /me. Se voltar a quebrar, você descobre imediatamente.\n\n## Testes de contrato de API: manter respostas estáveis para a UI e integrações\n\nTestes de contrato verificam que um endpoint mantém sua promessa: quais campos aparecem, quais tipos são e qual o formato de erro que o cliente pode esperar. Eles não tentam provar toda regra de negócio. Evitam uma das falhas mais comuns em código que muda rápido: uma mudança no backend que quebra a UI ou uma integração parceira silenciosamente.\n\nPara uma suíte mínima, escolha apenas os endpoints que mais fariam mal se mudassem. Normalmente são algumas chamadas que a UI faz em cada carregamento de página, mais qualquer coisa de que um sistema externo dependa.\n\nUma forma simples de escolher é olhar a aba de rede e os logs de erro, e então travar 2 a 3 endpoints críticos, como:\n\n- Login ou verificação de sessão (am I signed in?)\n- Perfil do usuário atual (who am I?)\n- A ação principal de criação (create order, save draft, post message)\n- Um endpoint de lista crítico (my projects, my invoices)\n\nCubra sucesso e falha. Muitas apps instáveis falham em caminhos chatos: headers de auth faltando, input inválido, sessões expiradas.\n\n### O que afirmar (e o que ignorar)\n\nTrave apenas as partes estáveis. Afirme coisas que uma pessoa pode ler e concordar. Pule campos voláteis que mudam a cada execução.\n\n- Campos obrigatórios existem (id, email, status) e os tipos fazem sentido\n- Respostas de erro sempre têm a mesma forma (code, message) e o status HTTP correto\n- Arrays são arrays, não às vezes null\n- Ignore timestamps, IDs aleatórios e ordenação, a menos que a ordenação faça parte da promessa\n\nEscreva expectativas em linguagem simples para que um fundador não técnico possa checar. Exemplo: “Se auth está faltando, /me retorna 401 com { code, message }. Se auth é válido, retorna 200 com { id, email }.” Essa regra sozinha evita muito retrabalho.\n\n## Testes de regressão: transformar correções em proteções permanentes\n\nTestes de regressão são os “este bug nunca pode voltar” tests. Em codebases geradas por IA, correções podem desaparecer na próxima vez que alguém ajustar um prompt, regenere um arquivo ou refatore uma função bagunçada. Uma suíte pequena de regressão faz suas correções persistirem.\n\nO melhor momento para adicionar um teste de regressão é logo depois de corrigir o bug, enquanto a falha ainda está fresca. Semanas depois você vai esquecer as entradas exatas e o impacto real do usuário.\n\nMantenha cada teste de regressão focado na menor reprodução possível. Capture só o que você precisa: as entradas específicas, os poucos passos que disparam o bug e o resultado esperado. Se o bug antigo exigia dez telas de setup, isso é sinal de que você precisa de um melhor ponto de teste, não um teste maior.\n\nUm padrão simples:\n\n- Recrie a requisição ou ação do usuário que falhava em um teste.\n- Afirme o comportamento errado que acontecia (código de status, mensagem de erro, dado errado).\n- Aplique a correção.\n- Atualize a asserção para o comportamento correto e mantenha-a precisa.\n\nNomes de testes são documentação subestimada. Um bom nome inclui o que quebrou e por que importa, por exemplo: rejects_login_when_token_is_missing_prevents_account_takeover.\n\nExemplo concreto: você corrigiu um bug de reset de senha que vazava se um usuário existia. O teste de regressão deve enviar um pedido de reset para um email inexistente e afirmar que a resposta continua genérica e consistente.\n\n## Passo a passo: construa uma suíte mínima em uma sessão focada\n\nFaça os testes fáceis de encontrar e enfadonhos de rodar. Crie uma estrutura pequena e uma regra de nomes que você ainda siga no mês seguinte:\n\n- tests/smoke/ para cheques “a app inicia mesmo?”\n- tests/contracts/ para checagens de forma de resposta de API\n- tests/regression/ para bugs que você já corrigiu\n\nDepois, adicione um punhado de testes que te deem confiança rápida. Mantenha o setup simples para que rodem igual em todas as máquinas. Um bom ponto de partida é:\n\n- 3 smoke tests (boot, um fluxo principal, uma API crítica)\n- 2 contract tests (seus dois endpoints mais usados)\n- 2 regression tests (seus dois últimos incidentes reais)\n\nAo escrever smoke tests, pense como um usuário cansado: “Abro a app, faço o principal, funciona.” Ao escrever contract tests, pense como front end: “Preciso de id, name e role, não de um rename surpresa.” Ao escrever regression tests, copie os passos exatos que quebraram em produção e então afirme o comportamento corrigido.\n\nRode tudo localmente primeiro e depois o mesmo comando no pipeline de deploy. Se os testes estiverem lentos, corte escopo, não precisão.\n\nUma regra mantém a suíte viva: se você mexer numa funcionalidade, adicione ou atualize um teste para ela.\n\n## Tornar os testes confiáveis: dados estáveis, setup estável, limpeza estável\n\nUma suíte mínima só ajuda se der a mesma resposta a cada execução. A maioria das “falhas aleatórias” não é aleatória. Vem de dados compartilhados, setup inconsistente ou testes que dependem de serviços externos.\n\nMantenha dados de teste separados dos reais. Use um banco de teste, um schema temporário ou um dataset descartável que possa ser apagado sem risco. Se os testes tocarem dados de produção, eles vão acabar corrompendo ou virando algo assustador de rodar.\n\nDeixe o setup previsível. Crie alguns usuários e papéis conhecidos e reutilize-os: um admin, um usuário normal e um usuário bloqueado. Mantenha credenciais fixas na configuração de teste para não correr atrás de mudanças depois.\n\nServiços externos são fonte comum de instabilidade. Se os testes chamarem email real, pagamentos ou webhooks, você verá timeouts, limites de taxa e falhas surpresa. Fake essas chamadas quando puder, ou stub para testar só “enviamos a requisição certa” e “lidamos com a resposta”.\n\nFixtures ajudam a evitar dados copiados que derivam. Mantenha um pequeno conjunto de builders para objetos comuns como usuário, projeto ou pedido. Use defaults claros e sobrescreva só o que o teste precisar.\n\nResete estado entre testes para que uma falha não envenene a próxima. Um loop simples: crie dados, execute a ação, afirme o que importa, depois limpe (rollback ou truncate) e resete caches/flags.\n\n## Erros comuns que desperdiçam tempo e criam testes frágeis\n\nA forma mais rápida de acabar sem testes é tentar testar tudo de uma vez. Se você buscar cobertura total no dia um, vai travar no setup, lutar com falhas e nunca entregar uma suíte útil.\n\nOutra armadilha é testar a coisa errada. Checagens de UI pixel-perfect e match de texto exato parecem tranquilizadoras, mas quebram com mudanças inocentes como um novo rótulo de botão. Testes mínimos devem focar em resultados: “usuário consegue entrar”, “total da fatura está correto”, “API retorna os campos que a UI precisa”.\n\nTestes ficam frágeis quando dependem da internet. APIs de pagamento, email ou analytics reais falham, limitam taxa ou mudam respostas. Stub terceiros e reserve um check end-to-end ocasional para staging, não para todo commit.\n\nCuidado com asserções frágeis. IDs, timestamps e mensagens geradas mudam sempre em protótipos bagunçados. Prefira cheques estáveis como códigos de status, campos chave e padrões simples (por exemplo, “createdAt existe e é uma data ISO”) em vez de comparar a string do timestamp exato.\n\nSe estiver lidando com flakiness, estas correções geralmente ajudam rápido:\n\n- Teste resultados, não pixels da UI ou texto exato\n- Stub APIs de terceiros e controle respostas\n- Evite afirmar IDs aleatórios e timestamps exatos\n- Adicione ao menos um teste de caminho ruim por endpoint crítico\n- Mantenha a suíte rápida (minutos, não dezenas de minutos)\n\nNão ignore caminhos de erro. Apps geradas por IA frequentemente falham em sessões expiradas, variáveis de ambiente faltando e payloads malformados. Se você testar só o happy path, continuará re-quebrando funcionalidades que já tinha corrigido.\n\n## Checklist rápido: sua suíte mínima está fazendo seu trabalho?\n\nUma suíte mínima só é mínima se protege o que você entrega e for rápida o suficiente para rodar sempre.\n\n### A suíte protege o básico\n\nSe qualquer um destes falhar, a app não está segura para deploy:\n\n- A app inicia limpo (sem variáveis de ambiente faltando, sem crash na inicialização).\n- Setup do banco funciona (migrations rodam em um banco limpo).\n- Uma página ou tela chave é renderizada (frequentemente o dashboard).\n- Suas top 3 APIs retornam os campos que a UI espera (nomes e tipos que você realmente usa).\n- Essas mesmas APIs retornam formas de erro consistentes (para a UI mostrar uma mensagem útil).\n\n### A suíte continua fácil de rodar e confiável\n\nVelocidade e repetibilidade importam mais que volume:\n\n- Os dois últimos bugs críticos que você corrigiu têm cada um um teste de regressão.\n- Testes terminam em alguns minutos num laptop comum.\n- Uma pessoa consegue rodar tudo com um único comando, sem conhecimento tribal.\n\nQuando um teste falha, você deveria aprender algo imediatamente. Uma boa falha aponta para uma causa provável (“token de login ausente”, “campo de API renomeado”), não um timeout vago.\n\n## Exemplo: proteger um fluxo de auth corrigido para não quebrar de novo\n\nUma história comum: um fundador lança um protótipo gerado por IA com login e assinaturas. Funciona em demos, mas usuários reais encontram falhas estranhas. Logins voltam pra tela de sign-in, sessões expiram instantaneamente e o checkout falha porque a app acha que o usuário está deslogado.\n\nAlguém conserta a lógica de autenticação, limpa cookies ou tokens, e a app finalmente mantém a sessão. Duas semanas depois, uma pequena mudança (muitas vezes em outra parte do código) chega e o login quebra de novo. Ninguém mexeu em “auth”, mas um middleware novo, um refactor ou uma mudança de ambiente alterou o comportamento.\n\nUma suíte mínima evita esse vai-e-volta colocando três pequenos guardiões no fluxo:\n\n- Um smoke test que acerta a rota de login e checa um sinal claro de sucesso (200 OK mais cookie de sessão ou token presente).\n- Um contract test que checa a forma da resposta do endpoint de sessão (por exemplo: user id, email, subscription status), para a UI não quebrar quando campos se moverem ou renomearem.\n- Um regression test que reproduz o bug exato que você viu, como “depois do login, GET /me retorna 401” ou “atualizar a página perde a sessão.”\n\nMantenha as checagens simples. Não tente testar todos os casos de borda. Proteja o que paga as contas: pessoas conseguem entrar e permanecer logadas.\n\nO benefício aparece na próxima vez que alguém muda código. Em vez de usuários reportarem “não consigo entrar”, o build falha rápido com uma mensagem como “campo subscriptionStatus ausente na resposta de sessão.” Isso vira um conserto de cinco minutos, não uma correria de dias.\n\nTambém reduz idas e vindas com contratados e agências. Você não discute mais se o auth funciona numa máquina. O teste é o árbitro.\n\n## Próximos passos: mantenha a suíte mínima e continue entregando com segurança\n\nUma suíte mínima só funciona se ficar ligada à dor real. O objetivo não é “mais cobertura.” É menos surpresas a cada mudança.\n\nEscolha seus próximos cinco testes com base no que realmente te custou tempo: tickets de suporte, outages e partes do app que você tem medo de tocar. Puxe os três últimos erros de produção (ou quase erros) e transforme cada um em um teste de regressão que falhe do mesmo jeito que falhou na vida real.\n\nPara manter o ritmo sem deixar os testes dominarem sua semana:\n\n- Depois de cada correção, adicione 1 pequeno teste de regressão que comprove que a correção segura.\n- Depois de cada incidente, adicione 1 smoke test que o teria detectado rapidamente.\n- A cada duas semanas, adicione 1 contract test para seu endpoint ou integração mais usada.\n- Mantenha uma lista curta de “pontos de ruptura” e aposente testes que já não refletem os riscos atuais.\n\nPare quando novos testes deixarem de pegar problemas reais. Esse é seu conjunto mínimo atual.\n\nSe a codebase for bagunçada, expandir testes rápido pode sair pela culatra. Quando o setup é imprevisível, você ganha testes frágeis que as pessoas ignoram. Nesse caso, faça uma passada de estabilização curta primeiro: garanta um caminho limpo de boot da app, crie um setup de banco de testes confiável e remova armadilhas óbvias como segredos expostos ou estado global frágil.\n\nSe você herdou um protótipo gerado por IA que continua regredindo, FixMyMess (fixmymess.ai) se especializa em diagnosticar e reparar codebases geradas por IA, e então adicionar o mínimo de smoke, contract e regression tests para que as correções não se desfaçam na próxima mudança.\n\nTrate sua suíte como um cinto de segurança: pequena, sempre ligada e focada nas colisões que você já teve.