Actúa como un ingeniero de calidad. Vamos a definir cómo se comprueba un cambio ANTES de implementarlo, no después. Es importante que las pruebas salgan del encargo, no del código, para que no acaben validando lo que la IA haya generado.
ENCARGO A IMPLEMENTAR:
[Pega aquí el encargo con sus criterios de aceptación]
CONTEXTO:
- Tecnologías del proyecto: [lenguaje y framework, o "no lo sé"]
- Herramienta de pruebas que ya usamos: [ej. Jest, Vitest, pytest, ninguna]
- Cómo se lanzan las pruebas hoy: [comando exacto, o "no hay pruebas"]
- Quién va a ejecutar las comprobaciones manuales: [yo, que programo / yo, que no programo / un compañero]
Devuélveme:
1. QUÉ HAY QUE PROBAR Y QUÉ NO. Lista breve de los comportamientos que merecen prueba y, aparte, lo que no la merece porque el coste supera el beneficio. Justifica ambas listas en una frase cada una.
2. PRUEBAS AUTOMÁTICAS. Para cada comportamiento de la lista anterior, el código de la prueba completo y listo para pegar, usando la herramienta que ya usamos (si no usamos ninguna, propón una habitual para este stack y explica en tres líneas cómo instalarla y lanzarla). Incluye obligatoriamente: el caso normal, al menos un caso límite y al menos un caso de error. Cada prueba con un nombre que describa el comportamiento esperado en español, no el nombre de la función.
3. GUION DE COMPROBACIÓN MANUAL. Entre 5 y 8 pasos numerados que cualquiera pueda seguir abriendo la aplicación, sin conocimientos técnicos. Formato por paso: "Acción → Resultado esperado". Incluye al menos un paso que compruebe que NO se ha roto algo que ya funcionaba.
4. DATOS DE PRUEBA. Qué datos concretos hacen falta para ejecutar todo lo anterior y cómo crearlos sin tocar datos reales de clientes.
5. SEÑALES DE ALARMA. Tres cosas que, si las ves después del cambio, significan que hay que echar marcha atrás aunque las pruebas pasen.
6. MARCHA ATRÁS. Los pasos exactos para deshacer el cambio si algo sale mal en producción.
No escribas el código de la funcionalidad. Solo las pruebas y el guion.
Plan de pruebas antes de dar el cambio por bueno
Genera las pruebas automáticas y el guion de comprobación manual de un cambio, escritos antes de tocar el código.
