با این پرامپت هوش مصنوعی، موارد آزمون جامع برای هر تابع تولید کنید
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
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).
نوشتن موارد آزمون جامع یکی از زمانبرترین بخشهای توسعه نرمافزار است — و یکی از اولین بخشهایی که هنگام نزدیک شدن مهلتها نادیده گرفته میشود. بیشتر مهندسان مسیر خوشحال و چند مورد مرزی را پوشش میدهند و دنبالهای طولانی از شرایط خطا و مقادیر حدی را بدون آزمایش رها میکنند. این پرامپت با تولید یک مجموعه آزمون کامل و سازمانیافته از صرفاً توضیحات یک تابع، این مشکل را حل میکند.
این پرامپت چه چیزی تولید میکند
توضیحات تابع، زبان و فریمورک خود و زمینه مرتبط درباره وابستگیها یا قوانین کسبوکار را به آن بدهید. چهار دسته آزمون سازمانیافته بازمیگرداند: آزمونهای مسیر خوشحال با رایجترین ورودیهای دنیای واقعی، آزمونهای موارد مرزی که مقادیر حدی و ورودیهای خالی/صفر را پوشش میدهند، آزمونهای سناریوی خطا برای انواع نامعتبر و ورودیهای ایجادکننده استثنا، و آزمونهای یکپارچهسازی که دقیقاً مشخص میکنند چه چیزی نیاز به شبیهسازی دارد.
هر آزمون شامل یک نام توصیفی مطابق با قراردادهای زبان شما، مقادیر ورودی، رفتار مورد انتظار و یک جمله توضیحی است. یک خلاصه پوشش در انتها، شکافهایی را فهرست میکند که نیازمند زمینه اضافی هستند — که سختترین بخش تضمین کیفیت برای درستی است.
چرا پرامپت به این شکل ساختاربندی شده است
بخش نقش، هوش مصنوعی را به عنوان یک متخصص تضمین کیفیت تنظیم میکند، نه یک دستیار عمومی. این کار خروجی را به سمت قراردادهای آزمایش حرفهای سوق میدهد — آزمونهای تکمسئولیتی، assertions رفتاری و نامگذاری توصیفی — به جای مثالهای اسباببازی.
فیلدهای زمینهای [درون کروشه] مهمترین بخش هستند. زبان و فریمورک، قراردادهای نامگذاری و نحو assertion را تعیین میکنند. وابستگیهای خارجی مشخص میکنند که چه چیزی نیاز به شبیهسازی دارد. قوانین کسبوکار تعیین میکنند که کدام موارد خطا حیاتی و کدام ظاهری هستند. حذف این فیلدها آزمونهای عمومی تولید میکند که با پایگاه کد واقعی شما مطابقت ندارند.
برچسب [REQUIRES MOCK] از رایجترین حالت شکست در آزمونهای تولیدشده توسط هوش مصنوعی جلوگیری میکند: حذف ضمنی آزمونهای یکپارچهسازی چون نوشتن آنها سختتر است. این برچسب آنها را به صراحت نشان میدهد تا دقیقاً بدانید چه چیزی در اجرای آزمون وجود ندارد.
خلاصه پوشش چیزی است که این پرامپت را از یک درخواست ساده متمایز میکند. شکافها را فهرست میکند — دسترسی همزمان، گرد کردن مختص به منطقه، اعمال کوپن یکبار مصرف — که دقیقاً مواردی هستند که مهندسان فراموش میکنند درباره آنها بپرسند تا زمانی که در تولید شکست بخورند.
مدلهای سازگار
این پرامپت با Claude Sonnet 4.6 بهترین عملکرد را دارد که قالب خروجی ساختاریافته را به طور قابل اعتماد مدیریت کرده و خلاصههای پوشش دقیق تولید میکند. GPT-4o و Gemini 1.5 Pro نیز نتایج باکیفیتی ارائه میدهند. Gemini 2.5 Flash برای آزمونهای ساده تکتابعی کافی است. از مدلهای کوچکتر یا تقطیرشده برای توابع با وابستگیهای خارجی متعدد خودداری کنید — آنها تمایل به از دست دادن موارد مرزی یکپارچهسازی دارند.
چه زمانی از این پرامپت استفاده کنیم
زمانی که در حال بررسی یک Pull Request هستید و به یک تحلیل شکاف آزمون سریع اما کامل نیاز دارید، زمانی که TDD را روی یک تابع جدید شروع کرده و میخواهید یک scaffold کامل قبل از نوشتن پیادهسازی داشته باشید، یا زمانی که کد قدیمی با پوشش آزمون حداقلی را حسابرسی میکنید، از آن استفاده کنید. این پرامپت ۸۰٪ مواردی را که یک مهندس عجول از دست میدهد در کسری از زمان پوشش میدهد.