إنشاء مجموعة اختبار كاملة من أي دالة أو وصف ميزة
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)
مشكلة كتابة الاختبارات يدويًا
اسأل أي مطور عما يتجاهله تحت ضغط المواعيد النهائية، وستأتي الاختبارات في كل مرة. ليس لأن المطورين لا يهتمون بالجودة — بل يهتمون — ولكن لأن كتابة اختبارات شاملة مملة ومتكررة ومرهقة ذهنيًا. عليك التفكير في المعاكس: ما الذي يكسر هذا؟ ما الذي لم أحسب حسابه؟ معظم المطورين في هذه الحالة يفوتون 30-40% من حالات الحافة المهمة.
تحل هذه المطالبة (Prompt) المشكلة بوضع التفكير المنهجي لمهندس ضمان جودة أول في قالب قابل لإعادة الاستخدام.
ما يجعل هذه المطالبة فعالة
تستخدم هذه المطالبة إطار تغطية بخمس فئات: المسار السعيد، حالات الحافة، الأخطاء، التكامل، والأمن. كل فئة ترتبط بنمط فشل مختلف في الإنتاج. تحديد تسمية الاختبارات باستخدام should_[behavior]_when_[condition] يجبر الذكاء الاصطناعي على أن يكون دقيقًا بدلاً من توليد أسماء اختبارات غامضة مثل test_1 أو testFunction_works. متطلب الإشارة إلى مشكلات قابلية الاختبار يلتقط المشكلات المعمارية — مثل التبعيات المقترنة بإحكام — قبل أن تتحول إلى ديون تقنية.
كيفية استخدامها
الصق المطالبة في Claude Sonnet 4.5 (أو GPT-4o). املأ الحقول الثلاثة ذات الأقواس: لغة البرمجة، إطار الاختبار، ووصف الدالة أو الميزة. بالنسبة للدالة، الصق الكود الفعلي. بالنسبة للميزة، الصق معايير القبول أو وصفًا باللغة الإنجليزية المبسطة لما تفعله.
المخرجات هي ملف اختبار جاهز للتشغيل بالإضافة إلى جدول ملخص التغطية. قم بتشغيله، وتحقق من اختبارات المخطط التفصيلي التي تحتاج إلى تطوير، وستحصل على مجموعة اختبار أساسية في دقائق بدلاً من ساعات.
التكيف مع لغات وأطر مختلفة
تعمل هذه المطالبة بشكل متساوٍ عبر الأنظمة البيئية. بالنسبة لبايثون، حدد pytest كإطار. بالنسبة لـ TypeScript، استخدم Jest أو Vitest. بالنسبة لجافا، استخدم JUnit 5. بالنسبة لـ Go، قل Go testing package. يتكيف هيكل المخرجات وفقًا لذلك — الذكاء الاصطناعي يعرف مصطلحات كل إطار وسيستخدم أسلوب التأكيد الصحيح، وأنماط المحاكاة (mock)، وتنظيم الملفات.
معاينة مخرجات مثال
بالنسبة لدالة calculateDiscount(price, memberTier) في TypeScript باستخدام Jest، تولد المطالبة حوالي 18-24 اختبارًا تغطي: تركيبات السعر/مستوى العضوية القياسية، مدخلات سعر صفرية، أسعار سالبة، سلاسل مستوى غير صالحة، معاملات فارغة (null)، حالات حافة الفاصلة العائمة، وعقد التكامل مع خدمة التسعير. يوضح جدول الملخص تغطية سطر تقدر بأكثر من 90٪.