Prompt for Generating Complete Test Cases from a Feature Description or Code Snippet
Why this prompt matters
Most weak AI testing prompts fail because they ask for tests in one vague sentence. That usually produces shallow happy-path ideas and misses dependency failures, boundary values, ambiguous requirements, and regression risks. This Prompt works better because it gives the model a clear role, concrete project context, explicit task categories, and a fixed output structure. That combination pushes the model to reason like a reviewer, separate test types cleanly, expose uncertainty, and surface missing product decisions before bugs escape into production.
What we use it for
Use this Prompt when an engineer, reviewer, or tech lead needs to pressure-test a new feature before merge. It is especially useful during pull request review, feature QA planning, API endpoint design, utility-function changes, and refactors that might silently break existing behavior. Instead of starting from a blank page, the reviewer can paste a feature description and code snippet, then get a categorized checklist of unit tests, integration test ideas, failure cases, and open questions to take back to the team.
Prompt
Role You are a senior software test engineer and code reviewer. You specialize in turning feature descriptions, code snippets, and product requirements into a practical test strategy that engineers can immediately implement. Context I am reviewing [FEATURE_OR_FUNCTION_NAME] in a [LANGUAGE_OR_FRAMEWORK] codebase. The goal is to generate a complete and implementation-aware test plan from the following inputs: - Feature description: [FEATURE_DESCRIPTION] - Code snippet or pseudocode: [CODE_SNIPPET_OR_PSEUDOCODE] - Expected behavior: [EXPECTED_BEHAVIOR] - Known constraints or business rules: [BUSINESS_RULES] - Dependencies or integrations: [DEPENDENCIES_AND_EXTERNAL_SYSTEMS] - Risk areas: [RISK_AREAS] - Existing test coverage, if any: [EXISTING_TEST_COVERAGE] Task Analyze the inputs and generate a comprehensive test case set. Include: 1. Core unit test scenarios 2. Edge cases and boundary conditions 3. Error handling and failure-path tests 4. Integration test ideas involving APIs, databases, queues, caches, auth, or third-party services when relevant 5. Regression risks and tests to protect previous behavior 6. Missing-requirements questions or ambiguities that should be clarified before implementation is approved 7. A short priority label for each test idea: Critical, High, Medium, or Low 8. For each test, briefly explain what it validates and why it matters Constraints - Base your suggestions only on the provided inputs and clearly label reasonable assumptions - Be specific, technical, and implementation-aware, not generic - Prefer actionable test cases over abstract advice - Include positive, negative, and adversarial scenarios where appropriate - If the code appears incomplete, identify the testability gaps - If relevant, mention mocking or fixture needs - Do not write full executable test code unless I explicitly ask for it - Keep the output readable for engineers performing code review Output Format Return the response in these sections: 1. Feature Summary 2. Assumptions 3. Unit Test Cases 4. Edge Cases and Boundary Conditions 5. Error and Failure Scenarios 6. Integration Test Ideas 7. Regression Test Focus 8. Missing Requirements / Clarifying Questions 9. Highest-Risk Areas
Result
1. Feature Summary The feature adds a password reset endpoint, POST /api/reset-password, that accepts an email address, generates a time-limited token, stores a hashed token record, and sends a reset email through an external mail API. If the email does not exist, the endpoint still returns a generic success message to avoid account enumeration. Tokens expire after 15 minutes and only the latest token should remain valid.
2. Assumptions - The system normalizes email addresses before lookup. - Token records are stored in the database with createdAt and expiresAt fields. - Existing rate limiting middleware is expected but not shown in the snippet. - Mail delivery failures are logged and surfaced internally, but external responses should not leak user existence.
3. Unit Test Cases - Critical: returns generic success for existing email. Validates intended happy path and non-enumerating response behavior. - Critical: returns the same generic success for unknown email. Prevents account discovery. - High: generates a token with correct expiration window. Confirms security-sensitive timing logic. - High: stores hashed token instead of raw token. Validates secure persistence behavior. - High: invalidates previously issued tokens for the same user. Protects against replay with stale reset links. - Medium: trims and normalizes mixed-case email input. Confirms consistent lookup behavior.
4. Edge Cases and Boundary Conditions - Empty string email, whitespace-only email, malformed email, and unusually long email input. - Multiple requests within a short interval from the same account. - Request arriving exactly near token expiry boundary. - Internationalized email formats if supported by product requirements.
5. Error and Failure Scenarios - Critical: database write fails after token generation. Verify no misleading partial state remains. - High: mail API times out. Confirm retry or failure logging behavior and safe external response. - High: user lookup layer throws exception. Validate error handling path and observability. - Medium: hashing library failure or unexpected null token. Ensure request does not succeed silently.
6. Integration Test Ideas - Verify endpoint creates one valid token row and invalidates earlier rows in the real database. - Verify mail API payload includes the reset link, token, and correct template variables. - Verify auth middleware, rate limiter, and audit logging interact correctly with this endpoint.
7. Regression Test Focus - Existing login and signup flows should remain unaffected by new token invalidation logic. - Email templates used by other account emails should not break if shared mail helpers changed.
8. Missing Requirements / Clarifying Questions - What is the exact rate limit policy per IP and per account? - Should mail delivery failure trigger retry, dead-letter handling, or manual alerting? - Are previously issued tokens invalidated only on new requests or also after successful reset? - Should suspended or unverified accounts receive reset emails?
9. Highest-Risk Areas The biggest risks are account enumeration, token replay, inconsistent invalidation of prior tokens, and silent failure between token creation and mail delivery. These areas deserve Critical or High priority coverage before release.
This Prompt is designed for engineers reviewing a new feature, function, or API change and wanting a sharper test plan than a vague request like write tests for this. It works best when you already have a feature description, a pull request summary, or a code snippet that shows the intended behavior. The structure matters: the Role section tells the model to think like a senior test engineer, the Context section supplies implementation details, the Task section forces coverage across unit test, edge case, error, integration test, regression, and requirement-clarification categories, and the Output Format keeps the response readable during code review. That makes the result much more useful than a generic test list because it surfaces missing requirements, highlights risk, and produces actionable scenarios engineers can convert into real tests quickly.