Genera una suite de pruebas completa a partir de cualquier función o descripción de funcionalidad
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)
El problema de escribir pruebas a mano
Pregúntale a cualquier desarrollador qué es lo que omiten cuando están bajo presión de plazos, y las pruebas aparecen siempre. No porque a los desarrolladores no les importe la calidad — les importa — sino porque escribir pruebas exhaustivas es tedioso, repetitivo y mentalmente agotador. Tienes que pensar en opuestos: ¿qué rompe esto? ¿Qué no tuve en cuenta? La mayoría de los desarrolladores en ese modo pierden entre un 30 y un 40% de los edge cases significativos.
Este prompt resuelve eso al incorporar el pensamiento sistemático de un ingeniero senior de QA en una plantilla reutilizable.
Qué hace efectivo a este prompt
El prompt utiliza un marco de cobertura de cinco categorías: happy path, edge cases, errores, integración y seguridad. Cada categoría se asigna a un modo de fallo diferente en producción. La restricción de nombrar las pruebas usando should_[behavior]_when_[condition] obliga a la IA a ser precisa en lugar de generar nombres vagos como test_1 o testFunction_works. El requisito de marcar problemas de testabilidad detecta problemas arquitectónicos — como dependencias fuertemente acopladas — antes de que se conviertan en deuda técnica.
Cómo usarlo
Pega el prompt en Claude Sonnet 4.5 (o GPT-4o). Completa los tres campos entre corchetes: tu lenguaje de programación, tu framework de pruebas y la descripción de la función o funcionalidad. Para una función, pega el código real. Para una funcionalidad, pega los criterios de aceptación o una descripción en inglés sencillo de lo que hace.
El resultado es un archivo de prueba listo para ejecutar más una tabla resumen de cobertura. Ejecútalo, revisa las pruebas esbozadas que necesitan desarrollo, y tendrás una suite de pruebas base en minutos en lugar de horas.
Adaptación para diferentes lenguajes y frameworks
El prompt funciona igualmente bien en todos los ecosistemas. Para Python, especifica pytest como framework. Para TypeScript, usa Jest o Vitest. Para Java, usa JUnit 5. Para Go, simplemente di Go testing package. La estructura de salida se adapta en consecuencia — la IA conoce los modismos de cada framework y utilizará el estilo de aserción, los patrones de mock y la organización de archivos correctos.
Vista previa de salida de ejemplo
Para una función calculateDiscount(price, memberTier) en TypeScript con Jest, el prompt genera aproximadamente entre 18 y 24 pruebas que cubren: combinaciones estándar de precio/nivel de membresía, entradas de precio cero, precios negativos, cadenas de nivel no válidas, parámetros nulos, casos límite de coma flotante y el contrato de integración con el servicio de precios. La tabla resumen muestra una cobertura de línea estimada superior al 90%.