Prompt para Gerar Casos de Teste Completos a partir de uma Descrição de Funcionalidade ou Trecho de Código
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.
Este Prompt foi projetado para engenheiros que estão revisando uma nova funcionalidade, função ou mudança em uma API e querem um plano de testes mais refinado do que um pedido vago como 'escreve testes para isso'. Funciona melhor quando você já tem uma descrição da funcionalidade, um resumo do Pull Request ou um trecho de código que mostra o comportamento esperado. A estrutura é importante: a seção Role instrui o modelo a pensar como um engenheiro de testes sênior, a seção Context fornece detalhes de implementação, a seção Task força a cobertura das categorias de teste unitário, edge case, erro, teste de integração, regressão e esclarecimento de requisitos, e o Output Format mantém a resposta legível durante a code review. Isso torna o resultado muito mais útil do que uma lista genérica de testes, porque revela requisitos ausentes, destaca riscos e produz cenários acionáveis que os engenheiros podem converter rapidamente em testes reais.