Gere uma suíte de testes completa a partir de qualquer função ou descrição de funcionalidade
Why this prompt matters
<p>Incomplete tests are the leading cause of regressions in production. A typical developer writing tests from memory covers 60-70% of edge cases — the remaining 30% is where bugs live. Every missed edge case is a future incident, a 2am page, or a data corruption bug discovered by a customer. Beyond bugs: code without proper tests blocks confident refactoring. You end up with unmaintainable spaghetti because nobody dares touch it. This prompt forces systematic coverage across happy paths, boundaries, failures, and integration points — the same coverage a dedicated QA engineer would produce in several hours, generated in under a minute.</p>
What we use it for
You wrote a function or shipped a feature and need full test coverage before merging. You have the code in front of you but writing tests feels slow — you keep forgetting edge cases and your PR review always comes back with 'what about null input?' or 'does this handle timeout?'
Prompt
Act as a senior software engineer and QA architect with deep expertise in test-driven development. Context: I have a [FUNCTION / FEATURE / MODULE] that I need fully tested. It is written in [PROGRAMMING LANGUAGE] and uses [FRAMEWORK / LIBRARY if any]. Here is the code or description: [PASTE YOUR FUNCTION OR FEATURE DESCRIPTION HERE] Task: Generate a comprehensive test suite for the above. Cover ALL of the following: 1. Happy-path unit tests — the standard inputs that should work correctly 2. Edge case unit tests — boundary values, empty inputs, maximum values, off-by-one scenarios 3. Error/failure scenarios — invalid types, null/undefined, out-of-range values, network failures, timeouts 4. Integration test outlines — how this function/feature interacts with [DEPENDENT SYSTEM / DATABASE / API] 5. Security-relevant tests if applicable — SQL injection, XSS, buffer overflow, authentication bypass Constraints: - Write tests in [TEST FRAMEWORK, e.g. Jest, pytest, JUnit, RSpec, Go testing] - Each test must have a clear, descriptive name following the pattern: should_[expected behavior]_when_[condition] - Do NOT write implementation code — only tests - Group tests into describe blocks by category (happy path, edge cases, errors, integration) - For each test you skip or outline without full code, add a comment explaining why and what it would verify Output Format: - Full, runnable test file with all imports - Section headers as comments (// === HAPPY PATH ===, // === EDGE CASES ===, etc.) - After the test file: a short summary table listing test count per category and estimated code coverage % - Flag any testability issues you see in the original code (e.g. tightly coupled dependencies that need mocking)
O problema de escrever testes manualmente
Pergunte a qualquer desenvolvedor o que ele pula quando está sob pressão de prazos, e os testes sempre aparecem. Não porque os desenvolvedores não se importam com qualidade — eles se importam — mas porque escrever testes abrangentes é tedioso, repetitivo e mentalmente desgastante. Você precisa pensar em opostos: o que quebra isso? O que eu não considerei? A maioria dos desenvolvedores nesse modo perde 30-40% dos edge cases significativos.
Este prompt resolve isso incorporando o pensamento sistemático de um engenheiro sênior de QA em um template reutilizável.
O que torna este prompt eficaz
O prompt usa um framework de cobertura de cinco categorias: happy path, edge cases, erros, integração e segurança. Cada categoria mapeia um modo de falha diferente em produção. A restrição de nomear testes usando should_[behavior]_when_[condition] força a IA a ser precisa em vez de gerar nomes vagos como test_1 ou testFunction_works. A exigência de sinalizar problemas de testabilidade captura problemas arquiteturais — como dependências fortemente acopladas — antes que se tornem dívida técnica.
Como usar
Cole o prompt no Claude Sonnet 4.5 (ou GPT-4o). Preencha os três campos entre colchetes: sua linguagem de programação, seu framework de teste e a descrição da função ou funcionalidade. Para uma função, cole o código real. Para uma funcionalidade, cole os critérios de aceitação ou uma descrição em inglês simples do que ela faz.
A saída é um arquivo de teste pronto para execução mais uma tabela de resumo de cobertura. Execute-o, verifique os testes esboçados que precisam de desenvolvimento, e você terá uma suíte de testes base em minutos em vez de horas.
Adaptação para diferentes linguagens e frameworks
O prompt funciona igualmente bem em todos os ecossistemas. Para Python, especifique pytest como framework. Para TypeScript, use Jest ou Vitest. Para Java, use JUnit 5. Para Go, apenas diga Go testing package. A estrutura de saída se adapta de acordo — a IA conhece os idiomas de cada framework e usará o estilo de asserção, padrões de mock e organização de arquivos corretos.
Pré-visualização de saída de exemplo
Para uma função calculateDiscount(price, memberTier) em TypeScript com Jest, o prompt gera aproximadamente 18-24 testes cobrindo: combinações padrão de preço/nível de associação, entradas de preço zero, preços negativos, strings de nível inválidas, parâmetros nulos, casos limite de ponto flutuante e o contrato de integração com o serviço de precificação. A tabela de resumo mostra cobertura de linha estimada acima de 90%.