Gere casos de teste exaustivos para qualquer função com este prompt de IA
Porque é que este prompt importa
Functions that handle money, authentication, or user permissions fail in production in exactly the ways a rushed happy-path test misses: a null price, an unknown user tier, a floating-point rounding edge case on a $0.01 item. A typical code review surfaces 3-5 test cases; this prompt generates 15-25 in 30 seconds, including the boundary conditions responsible for most 2am incidents.
Para que o usamos
You are reviewing a pull request that modifies billing calculation logic 20 minutes before standup. You need to confirm the tests cover all the critical cases — null inputs, boundary values, invalid user tiers — but writing them from scratch would take 45 minutes you do not have.
Prompt
Act as a senior QA engineer and software testing expert with 10+ years of experience in unit testing, integration testing, and test-driven development across multiple programming languages. I need comprehensive test coverage for the following function or feature: [PASTE YOUR FUNCTION DESCRIPTION OR CODE HERE] Language and framework: [e.g., Python with pytest, JavaScript with Jest, Java with JUnit 5, Go with the testing package, TypeScript with Vitest] Additional context (optional): - External dependencies: [e.g., PostgreSQL database, Stripe API, Redis cache] - Related functions: [describe any functions this calls or that call it] - Business rules: [any domain-specific constraints, e.g., "price can never be negative", "user tier must be one of: free, pro, enterprise"] Generate a complete test suite covering: 1. Happy path — all expected inputs producing correct outputs, including the most common real-world inputs 2. Edge cases — boundary values, empty strings, zero, negative numbers, null/undefined/None, maximum/minimum values, single-element lists, very long strings 3. Error scenarios — invalid types, out-of-range values, missing required parameters, exception-triggering inputs 4. Integration considerations — how this function interacts with any listed external dependencies; flag what would need mocking Constraints: - Use descriptive test names following this pattern: test_[scenario]_[expected_result] (or the equivalent convention for [LANGUAGE]) - Keep each test focused on ONE behavior — no multi-assertion mega-tests - Flag any test that requires mocking or a test fixture with a [REQUIRES MOCK] tag - Do not generate tests for implementation details — test behavior, not internals Output Format: Organize the output into four sections: ### Happy Path Tests ### Edge Case Tests ### Error Scenario Tests ### Integration Tests For each test, provide: - Test name - Input values - Expected output or behavior - One-sentence rationale (why this case matters) End with a Coverage Summary listing: total test count, which scenarios are covered, and any gaps that require additional context or manual testing.
Resultado
Happy Path Tests
test_calculate_discount_pro_user_returns_20_percent
Input: price=100.00, user_tier="pro", coupon_code=None
Expected: 80.00
Why: Validates the standard pro-tier discount (20%) on a round number.
test_calculate_discount_enterprise_user_with_coupon_stacks_discounts
Input: price=200.00, user_tier="enterprise", coupon_code="SAVE10"
Expected: 144.00 (40% enterprise + 10% coupon applied sequentially)
Why: Confirms discount stacking for enterprise users with valid coupons.
test_calculate_discount_free_user_no_discount
Input: price=49.99, user_tier="free", coupon_code=None
Expected: 49.99
Why: Free-tier users receive no discount; price must pass through unchanged.
Edge Case Tests
test_calculate_discount_zero_price_returns_zero
Input: price=0.00, user_tier="pro", coupon_code=None
Expected: 0.00
Why: Discounting a free item must never produce a negative price.
test_calculate_discount_very_small_price_rounds_correctly
Input: price=0.01, user_tier="enterprise", coupon_code=None
Expected: 0.01 (rounds up, never $0.00)
Why: Floating-point math on tiny prices often produces $0.006.
test_calculate_discount_price_at_max_float_boundary
Input: price=999999.99, user_tier="enterprise", coupon_code="SAVE10"
Expected: 539999.99 (within float tolerance plus or minus 0.01)
Why: Large prices expose floating-point precision errors at billing scale.
test_calculate_discount_expired_coupon_silently_ignored
Input: price=100.00, user_tier="pro", coupon_code="EXPIRED2023"
Expected: 80.00 (only tier discount; expired coupon ignored gracefully)
Why: Expired coupons must fail gracefully without surfacing exceptions to users.
Error Scenario Tests
test_calculate_discount_negative_price_raises_value_error
Input: price=-50.00, user_tier="pro", coupon_code=None
Expected: raises ValueError("Price cannot be negative")
Why: Negative prices signal upstream data corruption and must be caught at the boundary.
test_calculate_discount_unknown_tier_raises_value_error
Input: price=100.00, user_tier="vip", coupon_code=None
Expected: raises ValueError("Unknown user tier: vip")
Why: Unknown tiers should fail loudly, not silently default to free and deny earned discounts.
test_calculate_discount_none_price_raises_type_error
Input: price=None, user_tier="pro", coupon_code=None
Expected: raises TypeError
Why: None prices originate from missing database fields and cause arithmetic errors downstream.
Integration Tests
test_calculate_discount_coupon_lookup_calls_db_once [REQUIRES MOCK: CouponRepository]
Input: price=100.00, user_tier="pro", coupon_code="SAVE10"
Expected: CouponRepository.find called exactly once with "SAVE10"; result=81.00
Why: Ensures no redundant database calls when validating a single coupon.
test_calculate_discount_audit_log_created_on_success [REQUIRES MOCK: AuditLogger]
Input: price=100.00, user_tier="enterprise", coupon_code=None
Expected: AuditLogger.log called once with {original: 100.00, final: 60.00, tier: "enterprise"}
Why: Discount events must be auditable for finance reconciliation.
Coverage Summary
Total tests: 12 | Happy path: 3 | Edge cases: 4 | Error scenarios: 3 | Integration: 2
Gaps requiring additional context: concurrent coupon redemption (race condition, needs load-test harness); locale-specific rounding (JPY has no cents); single-use coupon redemption limits (needs business rule clarification).
Escrever casos de teste abrangentes é uma das partes mais demoradas do desenvolvimento de software — e uma das mais fáceis de cortar quando os prazos apertam. A maioria dos engenheiros cobre o caminho feliz e alguns casos de borda, deixando uma longa cauda de condições de erro e valores limite não testados. Este prompt resolve isso gerando um conjunto de testes completo e organizado a partir de uma simples descrição de função.
O que este prompt gera
Dê a ele a descrição de uma função, sua linguagem e framework, e qualquer contexto relevante sobre dependências ou regras de negócio. Ele retorna quatro categorias de teste organizadas: testes de caminho feliz com as entradas mais comuns do mundo real, testes de casos de borda que cobrem valores limite e entradas nulas/vazias, testes de cenário de erro para tipos inválidos e entradas que disparam exceções, e testes de integração que marcam exatamente o que precisaria de mock.
Cada teste inclui um nome descritivo seguindo as convenções da sua linguagem, valores de entrada, comportamento esperado e uma frase de justificativa. Um resumo de cobertura no final lista lacunas que exigem contexto adicional — que é a parte mais difícil de acertar no QA.
Por que o prompt é estruturado dessa forma
A seção Papel define a IA como um especialista em QA em vez de um assistente genérico. Isso direciona a saída para convenções de teste profissionais — testes de responsabilidade única, asserções comportamentais e nomenclatura descritiva — em vez de exemplos de brinquedo.
Os campos de contexto [entre colchetes] são a parte mais importante. A linguagem e o framework determinam as convenções de nomenclatura e a sintaxe de asserções. Dependências externas determinam o que precisa de mock. Regras de negócio determinam quais casos de erro são críticos versus cosméticos. Pular esses campos produz testes genéricos que não correspondem à sua base de código real.
A tag [REQUIRES MOCK] evita o modo de falha mais comum em testes gerados por IA: omitir silenciosamente testes de integração porque são mais difíceis de escrever. A tag os exibe explicitamente para que você saiba exatamente o que está faltando na execução do teste.
O Resumo de cobertura é o que diferencia isso de uma solicitação simples. Ele lista lacunas — acesso concorrente, arredondamento específico de localidade, aplicação de cupom de uso único — que são exatamente os casos que os engenheiros esquecem de perguntar até que falhem em produção.
Modelos compatíveis
Este prompt tem melhor desempenho com Claude Sonnet 4.6, que lida com o formato de saída estruturada de forma confiável e gera resumos de cobertura precisos. GPT-4o e Gemini 1.5 Pro também produzem resultados de alta qualidade. Gemini 2.5 Flash é suficiente para testes simples de função única. Evite modelos menores ou destilados para funções com múltiplas dependências externas — eles tendem a perder casos de borda de integração.
Quando usar este prompt
Recorra a ele ao revisar um Pull Request e precisar de uma análise rápida mas completa de lacunas de teste, ao iniciar TDD em uma nova função e quiser um scaffold completo antes de escrever a implementação, ou ao auditar código legado com cobertura de teste mínima. Ele captura 80% dos casos que um engenheiro apressado perderia em uma fração do tempo.