Prompt de pruebas unitarias con casos límite
Pruebas que cubren el caso feliz, los límites y los errores, sin pruebas que solo comprueban que no explota.
Actúa como desarrollador que escribe pruebas con criterio de revisión. CÓDIGO [CÓDIGO A PROBAR] CONTEXTO - Lenguaje y framework de test: [JEST / PYTEST / JUNIT / PHPUNIT] - Comportamiento esperado: [QUÉ DEBE HACER] - Entradas típicas: [EJEMPLOS] - Qué no puede romperse nunca: [REGLAS CRÍTICAS] SALIDA 1) LISTA DE CASOS — antes de escribir: feliz, límite, error y regresión. Justifica cuáles son límite. 2) PRUEBAS — código completo, con nombres que describen el comportamiento. 3) DATOS DE PRUEBA — con números reales, no «foo» y «bar». 4) QUÉ NO CUBRE — lo que estas pruebas no demuestran. 5) COBERTURA ÚTIL — qué rama queda sin cubrir y si merece la pena. 6) PARA QUE NO SE ROMPA — una prueba de integración mínima si las unitarias no bastan. REGLAS - Los nombres de los tests dicen qué se espera, no qué método se llama. - Sin mocks innecesarios: si hace falta mockear todo, el diseño delata un problema. - Cada prueba falla por una sola razón.
La prueba se escribe para la próxima persona que toque el código, no para el informe de cobertura.
02 — Variables
Rellena los corchetes
Los campos resaltados son los sitios donde van tus datos. No hace falta rellenarlos todos: lo que dejes vacío lo completa el modelo con su propio criterio.
[CÓDIGO A PROBAR]
[JEST / PYTEST / JUNIT / PHPUNIT]
[QUÉ DEBE HACER]
[EJEMPLOS]
[REGLAS CRÍTICAS]
03 — Cómo se usa
Cómo usarlo, paso a paso
- 01
Escribe primero la lista de casos y después el código: empezar por el código produce pruebas que confirman lo que ya hace.
- 02
Los casos límite importan más que los felices: vacío, cero, negativo, muy grande y nulo.
- 03
Un test con nombre genérico como test1 no dice nada cuando falla en CI.
04 — Variantes
El mismo prompt, otro resultado
Un prompt no resuelve todos los casos. Estas variantes piden el mismo trabajo con otro tono, otra longitud o otro formato: elige la que encaje.
Legado sin pruebas
Mismo formato para código existente: primero pruebas de caracterización que fijen el comportamiento actual, incluidos los fallos.
Código asíncrono
Mismo formato para código asíncrono: tiempos de espera, orden de respuestas y fallos de red simulados.
05 — Consejos
Notas que suben el resultado de nivel
- Una prueba que nunca puede fallar no prueba nada. Si cambias el código y sigue en verde, revisa qué está comprobando.
- Los casos límite son la diferencia entre una suite de escaparate y una suite que evita incidentes.
06 — Preguntas
Preguntas frecuentes sobre Programación y código
¿Cuánta cobertura necesito?
La cobertura mide ejecución, no verificación. Un 70 % con casos límite vale más que un 95 % de pruebas triviales.
¿Debo probar solo lo público?
En general sí: probar implementación acopla las pruebas al código y las rompe en cada refactor.
Siguiente
También te puede servir
Prompt para generar código que se puede mantener
Código que puedes mantener después: supuestos declarados, errores tratados, pruebas incluidas y una decisión de diseño justificada.
Intermedio ChatGPTClaudePrompt para encontrar errores en el código
Un error tiene causas ordenadas por probabilidad, no parches. El prompt exige reproducción mínima y pruebas que confirmen cada hipótesis.
Intermedio ChatGPTClaudePrompt de refactorización: sin cambiar comportamiento
Refactoriza código sin romperlo: primero se fija el comportamiento con pruebas, después se cambia por pasos que se pueden deshacer.
Avanzado ChatGPTClaudePrompt de Python listo para ejecutar
Un script de Python que funciona a la primera: entradas, rutas, errores tratados y el comando exacto para ejecutarlo.
InicialEsta página la ha preparado el equipo editorial de CopyPromt y se publicó por primera vez el 25 octubre 2026. Los prompts están escritos para funcionar en varios modelos; los nombres de marca se citan solo a modo de identificación.