Template de prompt
Um prompt para testes unitários que verificam comportamento, não detalhes internos.
Este template fornece contrato, dependências, casos de borda e convenções do projeto para o agente escrever testes focados. Ele desencoraja simulações excessivas, asserções fracas e testes que repetem a implementação.
Revisado em 22 de setembro de 2026 · Os templates e exemplos usam dados fictícios.
Quando usar este prompt para testes unitários
Use-o quando o comportamento de uma função, serviço, hook ou componente puder ser descrito como contrato. Ele serve para ampliar cobertura, proteger uma correção ou especificar um comportamento pequeno antes da implementação.
Evite pedir “todos os testes possíveis”. Identifique riscos relevantes: limites incorretos, erros errados, efeitos duplicados, falhas de autorização, dependência de tempo ou integrações não determinísticas.
Template reutilizável
Prompt para geração de testes unitários
# Testes unitários para {{alvo}}
## Contexto
- Projeto: {{projeto}}
- Linguagem, framework e executor de testes: {{linguagem_framework}}
- Contrato de comportamento observável: {{contrato_comportamento}}
- Dependências e fronteiras externas: {{dependencias}}
- Casos de borda conhecidos: {{casos_borda}}
- Convenções de teste existentes: {{estilo_testes}}
<instructions>
Inspecione a implementação e os testes próximos antes de escrever novos testes. Teste o comportamento observável, não detalhes privados da implementação. Cubra um caminho feliz realista, falhas do contrato, valores-limite e os casos de borda informados.
Simule apenas fronteiras reais, como rede, armazenamento, tempo, aleatoriedade ou serviços externos. Não enfraqueça as asserções, não duplique a lógica da implementação dentro dos testes e não altere o comportamento de produção apenas para fazer um teste passar. Identifique as premissas quando o contrato estiver incompleto.
</instructions>
<output_format>
1. Matriz de cobertura de comportamentos e riscos
2. Premissas ou detalhes ausentes do contrato
3. Código completo dos testes seguindo as convenções do projeto
4. Comandos para executar os testes focados
5. Lacunas restantes que exigem testes de integração ou ponta a ponta
</output_format>O que o agente precisa saber
{{alvo}}
Função, classe, serviço, hook ou componente sob teste.
{{contrato_comportamento}}
Entradas, saídas, erros, mudanças de estado e efeitos visíveis ao consumidor.
{{dependencias}}
Fronteiras reais, como armazenamento, rede, tempo, aleatoriedade, filas ou serviços externos.
{{estilo_testes}}
Exemplos próximos, nomes, fixtures, fábricas e estratégia de simulação preferida.
Exemplo: criação idempotente de pedido
Alvo: criarPedido(comando) em um serviço TypeScript com Vitest.
Contrato: Uma nova chave cria um pedido; uma chave repetida retorna o existente; totais inválidos falham antes de persistir.
Dependências: Repositório de pedidos e cliente de pagamento. O repositório é a fronteira transacional.
Casos de borda: Chamadas concorrentes, timeout de pagamento, total zero e conflito no repositório.
Estilo: Usar builders existentes, asserções explícitas e relógio falso somente para timeouts.
Uma boa resposta diferencia o que os testes isolados comprovam do cenário concorrente que pode exigir um teste de integração com transação real.
Rejeite testes que apenas parecem convincentes
- Asserções descrevem comportamento visível e resultados relevantes.
- Falhas verificam o erro e efeitos que não podem ocorrer.
- Mocks representam fronteiras reais, não todo colaborador.
- Dados incluem valores realistas e limites.
- Lacunas de integração e ponta a ponta ficam explícitas.
Testes unitários são uma camada
Uma suíte unitária aprovada não comprova restrições do banco, comportamento do navegador, contratos de rede ou configuração de deploy. Peça o menor teste de nível superior quando o risco atravessar uma fronteira real.