Como usar a IA para escrever testes úteis
Transforme uma mudança de comportamento em cobertura focada com Django, node:test ou Playwright e dados descartáveis.
Substitua os valores entre colchetes antes de enviar. Forneça os arquivos públicos relevantes da release alvo exata; use exemplos sintéticos e deixe credenciais, campanhas privadas e material proprietário fora do contexto.
O que você vai construir
Proteja um limite real, como rejeitar um recurso de outra campanha ou evitar efeitos duplicados em uma repetição. Escolha a menor camada de teste capaz de observar esse comportamento.
Contexto para fornecer à IA
docs/pt-BR/testing.md: comandos reais, banco explícito de testes e isolamento de fixtures de navegador.
O serviço/controlador alterado, testes próximos e um resultado esperado claro.
As ferramentas atuais: Django/unittest, node:test e scripts independentes de Playwright.
Passo a passo
Escreva o comportamento desejado e um exemplo de falha antes de gerar asserts.
Peça à IA que justifique a escolha entre serviço, JavaScript puro e navegador real.
Reserve banco, mídia, estado de módulos, portas e saídas independentes.
Execute o teste focado; amplie apenas quando uma falha nova ou dúvida pendente justificar.
Copie e adapte este prompt
Repositório: [checkout local ou repositório público]
Release alvo do host: [versão instalada/solicitada; preserve-a]
Escopo e autorização: [o que pode ser alterado/publicado]
Adicione cobertura de regressão significativa para [comportamento] em [domínio responsável].
Leia docs/pt-BR/testing.md e as fixtures próximas. Use Django/unittest, node:test ou o harness Playwright documentado; não invente npm test na raiz nem runner pytest.
Isole dados, mídia, pacotes, portas e saídas sem editar o .env real. Alterar apenas GRAVEWRIGHT_DATABASE não muda o banco Django de testes configurado explicitamente.
Cubra o limite real: [usuário autorizado/negado, repetição do mesmo UUID, atualização após conflito ou resultado renderizado]. Use UUID novo para cada operação lógica nova.
Evite testes que apenas repetem constantes da implementação ou documentação. Preserve os asserts e explique por que o teste falharia sem a correção.
Execute o comando mais focado e informe resultados reais. Verificação apenas de fonte não substitui execução nativa/navegador quando a mudança a exige.
Examine os arquivos reais e APIs suportadas antes de propor código. Não invente comandos, campos, endpoints ou capacidades de pacotes.
Use dados de teste descartáveis e ferramentas/caches locais à instalação. Explique requisitos sem suporte e valide o resultado com as ferramentas reais do projeto.
Entregue arquivos ou passos concretos no editor, verificações realizadas e limitações pendentes.Como validar
Revise o isolamento da fixture antes de comandos que possam substituir o banco de testes.
Confira que os asserts observam o comportamento no limite correto.
Registre comando e resultado; mantenha logs na saída local descartável.
Pronto quando
Um teste focado detecta a regressão original, usa estado isolado e passa com a implementação desejada.
Continue pela referência de módulos, API pública e guia de testes.