تولید یک مجموعه کامل تست از هر تابع یا توصیف ویژگی
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)
مشکل نوشتن تست بهصورت دستی
از هر توسعهدهندهای بپرسید که در زیر فشار ددلاین چه کاری را نادیده میگیرد و همیشه نام تستها مطرح میشود. نه به این دلیل که توسعهدهندگان به کیفیت اهمیت نمیدهند — که میدهند — بلکه به این دلیل که نوشتن تستهای جامع کاری خستهکننده، تکراری و از نظر ذهنی پرهزینه است. باید بهصورت معکوس فکر کنید: چه چیزی این را خراب میکند؟ چه چیزی را در نظر نگرفتهام؟ اغلب توسعهدهندگان در این حالت ۳۰ تا ۴۰ درصد موارد مرزی معنیدار را از دست میدهند.
این پرامپت با قرار دادن تفکر سیستماتیک یک مهندس ارشد تضمین کیفیت در یک الگوی قابل استفاده مجدد، این مشکل را حل میکند.
چه چیزی این پرامپت را مؤثر میسازد
این پرامپت از یک چارچوب پوشش پنجدستهای استفاده میکند: مسیر خوشحال، موارد مرزی، خطاها، یکپارچهسازی و امنیت. هر دسته به یک حالت خرابی متفاوت در تولید نگاشت میشود. محدودیت نامگذاری تستها با استفاده از 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، پرامپت تقریباً ۱۸ تا ۲۴ تست تولید میکند که پوشش میدهد: ترکیبات استاندارد قیمت/رتبه عضویت، ورودیهای قیمت صفر، قیمتهای منفی، رشتههای رتبه نامعتبر، پارامترهای null، موارد مرزی اعداد اعشاری و قرارداد یکپارچهسازی با سرویس قیمتگذاری. جدول خلاصه پوشش خط تخمینی را بالای ۹۰٪ نشان میدهد.