توليد مجموعات اختبار شاملة من وصف دالة
Why this prompt matters
Skipping edge cases is where most production bugs live. A function that works for normal inputs but silently returns wrong results for empty strings, zero values, or concurrent writes will pass a cursory manual test and still break in production. Developers without a structured checklist miss 30-50% of edge cases on average — this prompt enforces completeness every time.
What we use it for
You've just written a pricing function, an authentication handler, or a data-processing pipeline — and you need to ship it tomorrow. You paste the function into this prompt and get back a full test suite with happy paths, boundary values, and error scenarios already written, so you can move to code review instead of spending 90 minutes hand-crafting tests.
Prompt
Act as a senior QA engineer and software testing expert with 10+ years of experience writing test suites for production-grade code. I have a function or feature that needs comprehensive test coverage. Here is the description: [PASTE YOUR FUNCTION/FEATURE DESCRIPTION, CODE SNIPPET, OR SPECIFICATION HERE] Technology stack: [YOUR LANGUAGE AND FRAMEWORK — e.g., Python/pytest, JavaScript/Jest, TypeScript/Vitest, Java/JUnit, Go/testing] Testing framework: [YOUR TESTING FRAMEWORK] Code maturity: [NEW CODE / EXISTING CODE WITH KNOWN BUGS / REFACTORING IN PROGRESS] Your task: 1. Generate a complete set of unit tests covering: - Happy path (standard inputs with expected outputs) - Edge cases (boundary values, empty inputs, maximum inputs, special characters) - Error scenarios (invalid inputs, type mismatches, null/undefined, out-of-range values) - State mutations (if the function has side effects, test them explicitly) 2. List integration test outlines (what you'd test at the integration layer, without writing full code) 3. Identify any untestable scenarios and explain why (dependency on external systems, timing issues, etc.) 4. Add a one-line comment above each test explaining what it's asserting and why it matters Constraints: - Tests must be independent — no test should rely on another's side effects - Use descriptive test names in the format: [method]_[scenario]_[expected outcome] - Do NOT mock anything unless you explain exactly why the mock is necessary - Prioritize tests by impact: mark each as HIGH / MEDIUM / LOW risk Output format: ## Unit Tests (with priority labels) [Full test code in [YOUR TESTING FRAMEWORK]] ## Integration Test Outlines [Bullet list of integration scenarios to cover] ## Untestable Scenarios [List with explanations] ## Coverage Summary [Estimated line/branch coverage and what's missing]
Result
Here is the full test suite for calculate_discount(price, coupon_code, user_tier) using Python/pytest:
import pytest
from pricing import calculate_discount
# [HIGH] Standard discount applied correctly for a valid coupon and premium user
def test_calculate_discount_valid_coupon_premium_user_applies_discount():
assert calculate_discount(100.0, "SAVE20", "premium") == 80.0
# [HIGH] Free users receive no additional tier discount beyond coupon
def test_calculate_discount_valid_coupon_free_user_no_tier_bonus():
assert calculate_discount(100.0, "SAVE20", "free") == 80.0
# [HIGH] Invalid coupon code returns full price without discount
def test_calculate_discount_invalid_coupon_returns_full_price():
assert calculate_discount(100.0, "FAKECODE", "premium") == 100.0
# [HIGH] Price of zero returns zero regardless of coupon or tier
def test_calculate_discount_zero_price_returns_zero():
assert calculate_discount(0.0, "SAVE20", "premium") == 0.0
# [MEDIUM] Negative price raises ValueError — cannot discount negative amounts
def test_calculate_discount_negative_price_raises_value_error():
with pytest.raises(ValueError, match="Price must be non-negative"):
calculate_discount(-50.0, "SAVE20", "premium")
# [MEDIUM] Empty coupon string treated as no coupon — full price returned
def test_calculate_discount_empty_coupon_no_discount():
assert calculate_discount(100.0, "", "premium") == 100.0
# [MEDIUM] None coupon treated as no coupon — does not raise, returns full price
def test_calculate_discount_none_coupon_no_discount():
assert calculate_discount(100.0, None, "premium") == 100.0
# [MEDIUM] Unknown user_tier defaults to free-tier behavior, no tier bonus
def test_calculate_discount_unknown_tier_defaults_to_free():
assert calculate_discount(100.0, "SAVE20", "vip") == 80.0
# [LOW] Very large price value does not cause overflow or floating-point error
def test_calculate_discount_very_large_price_precision():
result = calculate_discount(1_000_000.0, "SAVE20", "premium")
assert abs(result - 800_000.0) < 0.01
# [LOW] Coupon code is case-insensitive — "save20" works like "SAVE20"
def test_calculate_discount_coupon_case_insensitive():
assert calculate_discount(100.0, "save20", "premium") == 80.0
Integration Test Outlines
- Apply coupon from the database — verify the discount matches the stored percentage for that coupon record
- Apply discount to a cart with multiple line items — verify totals are recalculated correctly
- Expired coupon in the database — verify
calculate_discountreturns full price and logs the expiry event - Concurrent requests with the same coupon (single-use coupon) — verify only one request succeeds
Untestable Scenarios
- Real-time coupon expiry race condition — coupon expires between the validity check and the discount application; requires a database transaction test outside unit scope
- External pricing API availability — if
calculate_discountcalls a third-party pricing service, that call cannot be reliably tested without a staging environment
Coverage Summary
Estimated line coverage: 94%. Estimated branch coverage: 87%. Missing: the internal retry logic on database timeout (lines 47-52) — requires a mock of the DB connection pool, which should be covered in an integration test.
كتابة الاختبارات مهمة يعرف المطورون أنه يجب القيام بها بدقة، ونادرًا ما يفعلون. ليس بسبب الكسل — بل بسبب ضغط الوقت والعبء المعرفي لتعداد كل حالة حافة من الصفر. هذا الـ Prompt يزيح عبء التعداد عن كاهلك إلى الذكاء الاصطناعي، لتتمكن من التركيز على مراجعة المخرجات بدلاً من توليدها.
ما الذي يميز هذا الـ Prompt
معظم أوامر "اكتب اختبارات لهذا الكود" ترجع بضع تأكيدات على المسار السعيد وتعتبر المهمة منتهية. هذا الـ Prompt يفرض عقدًا مختلفًا: يجب على الذكاء الاصطناعي العمل عبر أربع فئات متميزة قبل أن ينتهي — المسار السعيد، حالات الحافة، سيناريوهات الخطأ، وتحولات الحالة. هذا الهيكل يلتقط 30-50% من حالات الحافة التي يفوتها المطورون عادةً عند كتابة الاختبارات تحت ضغط الوقت.
شكل المخرجات مهم أيضًا. طلب أسماء اختبارات وصفية بنمط [method]_[scenario]_[expected outcome] يضمن بقاء مجموعة الاختبار قابلة للقراءة بعد أشهر، عندما يغادر المؤلف الأصلي. طلب تعليق توضيحي لكل اختبار يعني أن أي مطور جديد يمكنه فهم ما يحمي كل تأكيد — وليس فقط ما يفعله.
كيفية الاستخدام
الصق الدالة الخاصة بك، أو وصفًا باللغة الإنجليزية البسيطة، أو حتى مستند مواصفات في الحقل المحدد. حدد لغتك وإطار العمل — سينتج الذكاء الاصطناعي كودًا قابلًا للتشغيل، وليس كودًا زائفًا. اضبط مؤشر نضج الكود على EXISTING CODE WITH KNOWN BUGS وسيقوم الذكاء الاصطناعي أيضًا بتحديد المسارات المعرضة للأخطاء بناءً على هيكل الكود.
قيود الـ Mock مقصودة. عمل Mock لكل شيء هو أسهل طريقة لبناء مجموعة اختبارات تنجح ولكنها لا توفر أي ثقة. بإجبار الذكاء الاصطناعي على تبرير أي Mock يقدمه، تُبقي مجموعة الاختبار متجذرة في السلوك الحقيقي.
تسميات الأولوية
يحصل كل اختبار على تصنيف مخاطرة HIGH / MEDIUM / LOW. يتيح لك ذلك تخطي اختبارات LOW أثناء إصدار محدود الوقت والعودة إليها في الـ Sprint التالي — دون فقدان تتبع ما تم تخطيه. كما يسرّع مراجعة الكود: يمكن للمراجعين رؤية وهلة ما إذا كانت مسارات HIGH-risk مغطاة.
يعمل بشكل أفضل مع
Claude Sonnet 4.6 أو GPT-4o. للدوال المعقدة ذات الشروط المتداخلة بعمق، يميل Claude إلى إنتاج تغطية فروع أكثر شمولاً. للكود الجديد في أطر عمل أحدث، GPT-4o بنفس الكفاءة. يتعامل كلا النموذجين مع هذا الـ Prompt بشكل موثوق — لا تستخدم نموذجًا أصغر لهذه المهمة، لأنه غالبًا ما يحذف سيناريوهات الخطأ.