Por qué está escrito así
Si solo pides "haz pruebas para este código", la IA suele generar una docena de casos donde todo funciona bien en escenarios ideales. Ver que todas las pruebas pasan da una falsa sensación de seguridad, pero se omiten los casos límite y las excepciones, que es donde realmente se esconden los errores.
El apartado de la tarea ataca este problema directamente. Al obligar a dividir los casos en "Flujo normal · Valores límite · Fallos y excepciones", la IA tiene que releer las condiciones lógicas del código. Siguiendo el ejemplo anterior, puntos de corte como 30 y 50, o excepciones para valores negativos y 0, salen a la luz de inmediato.
En cuanto al formato, pedir primero una tabla antes del código optimiza la revisión: ver el código directo suele distraer con la sintaxis, mientras que la tabla permite detectar a simple vista qué casos faltan. La columna "Razón para incluir este caso" ayuda a que el modelo filtre pruebas redundantes.
El límite de no superar 12 pruebas evita listas interminables de casos felices con entradas repetitivas. Esta restricción fuerza a la IA a priorizar los casos críticos y de frontera.
El último párrafo exige una autoverificación para eliminar pruebas triviales o inútiles. Delimitar el código con """ evita que los comentarios o cadenas de texto internos se confundan con instrucciones.
¿Términos desconocidos? Consulta Aha AI: output-format, hallucination
Comparado con un mal ejemplo
Hazme las pruebas para esta función
(pegar código)
Generará unas pocas pruebas básicas con entradas válidas. Faltarán los valores límite que cambian las condiciones y el manejo de excepciones. Además, suele asumir dependencias o fixtures inexistentes que impedirán ejecutar las pruebas de inmediato. Confiar en que los tests pasen solo porque son fáciles de aprobar es el mayor riesgo.
Variaciones
Detectar casos faltantes en pruebas existentes
A continuación se incluye una función junto con sus pruebas actuales. No escribas pruebas nuevas directamente; primero extrae en una tabla únicamente los casos que aún no han sido cubiertos. Las columnas deben ser: "Caso no cubierto | Por qué es necesario | Nivel de riesgo". Después, escribe solo 3 pruebas en {{herramienta de prueba}} priorizando los casos de mayor riesgo.
""" {{código fuente}} """
Úsalo cuando ya tienes pruebas escritas. Pedir primero la tabla de casos faltantes evita generar pruebas duplicadas o redundantes.
Diagnosticar por qué falla una prueba
La siguiente prueba en {{herramienta de prueba}} está fallando. Determina primero si el error está en el código o en la prueba, y explica tu razonamiento. No propongas cambiar los valores esperados de la prueba solo para forzar que pase.
""" {{código fuente}} """
Cuando una prueba falla, la IA tiende a modificar el valor esperado en el test en vez de arreglar la lógica. Esta variante bloquea ese atajo.
Notas por modelo
Asegúrate siempre de ejecutar las pruebas en tu entorno local. Un código de prueba no ejecutado puede parecer correcto a simple vista pero fallar al correrlo.
La sintaxis de las aserciones puede variar según la versión del framework. Si el resultado no coincide con tu entorno, añade una aclaración como: "Uso la versión X de {{herramienta de prueba}}".
Prompts relacionados
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos