Claude Sonnet 4.6 (recommended); also works with GPT-4o and Gemini 1.5 ProYou 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.Developer Tools

Generate exhaustive test cases for any function with this AI prompt

May 26, 2026

Why this prompt matters

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.

What we use it for

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.

Result

<h3>Happy Path Tests</h3>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.<h3>Edge Case Tests</h3>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.<h3>Error Scenario Tests</h3>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.<h3>Integration Tests</h3>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.<h3>Coverage Summary</h3>Total tests: 12 | Happy path: 3 | Edge cases: 4 | Error scenarios: 3 | Integration: 2Gaps 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).

Writing comprehensive test cases is one of the most time-consuming parts of software development — and one of the easiest to cut short when deadlines loom. Most engineers cover the happy path and a handful of edge cases, leaving a long tail of error conditions and boundary values untested. This prompt solves that by generating a full, organized test suite from nothing more than a function description.<h2>What This Prompt Generates</h2>Give it a function description, your language and framework, and any relevant context about dependencies or business rules. It returns four organized test categories: happy path tests with the most common real-world inputs, edge case tests covering boundary values and null/empty inputs, error scenario tests for invalid types and exception-triggering inputs, and integration tests that flag exactly what would need mocking.Each test includes a descriptive name following your language's conventions, input values, expected behavior, and a one-sentence rationale. A coverage summary at the end lists gaps that require additional context — which is the hardest part of QA to get right.<h2>Why the Prompt Is Structured This Way</h2>The Role section sets the AI as a QA expert rather than a generic assistant. This shifts output toward professional testing conventions — single-responsibility tests, behavioral assertions, and descriptive naming — instead of toy examples.The [bracketed] context fields are the most important part. Language and framework determine naming conventions and assertion syntax. External dependencies determine what needs mocking. Business rules determine which error cases are critical versus cosmetic. Skipping these fields produces generic tests that do not match your actual codebase.The [REQUIRES MOCK] tag prevents the most common failure mode in AI-generated tests: silently omitting integration tests because they are harder to write. The tag surfaces them explicitly so you know exactly what is missing from the test run.The Coverage Summary is what separates this from a simple request. It lists gaps — concurrent access, locale-specific rounding, single-use coupon enforcement — which are exactly the cases engineers forget to ask about until they fail in production.<h2>Compatible Models</h2>This prompt performs best with Claude Sonnet 4.6, which handles the structured output format reliably and generates accurate coverage summaries. GPT-4o and Gemini 1.5 Pro also produce high-quality results. Gemini 2.5 Flash is sufficient for simple, single-function tests. Avoid smaller or distilled models for functions with multiple external dependencies — they tend to miss integration edge cases.<h2>When to Use This Prompt</h2>Reach for it when reviewing a pull request and needing a quick but thorough test gap analysis, when starting TDD on a new function and wanting a complete scaffold before writing the implementation, or when auditing legacy code with minimal test coverage. It catches 80% of the cases a rushed engineer would miss in a fraction of the time.

testingdeveloper toolsai-promptsunit-testsqacoding