Prompt pour générer des cas de test complets à partir d'une description de fonctionnalité ou d'un extrait de code
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.
Ce Prompt est conçu pour les ingénieurs qui examinent une nouvelle fonctionnalité, une fonction ou un changement d'API et qui souhaitent un plan de test plus précis qu'une demande vague comme « écris des tests pour ça ». Il fonctionne mieux quand vous avez déjà une description de fonctionnalité, un résumé de Pull Request ou un extrait de code qui montre le comportement attendu. La structure compte : la section Role demande au modèle de penser comme un ingénieur test senior, la section Context fournit les détails d'implémentation, la section Task impose une couverture dans les catégories test unitaire, cas limite, erreur, test d'intégration, régression et clarification des exigences, et le Output Format rend la réponse lisible pendant la revue de code. Cela rend le résultat bien plus utile qu'une liste générique de tests, car ça fait émerger les exigences manquantes, met en lumière les risques et produit des scénarios actionnables que les ingénieurs peuvent rapidement transformer en vrais tests.