Pruebas: cómo evitar que tu app se rompa

Tu app se va a romper. La pregunta es si te vas a enterar tú o tus usuarios. Y con AI hay algo peor: cada vez que le pides un cambio, puede romper lo que ya funcionaba sin que nadie lo note. Las pruebas son lo que te avisa.

Esta guía tiene dos partes: primero te explico los 3 tipos de prueba en español simple, y después los prompts para revisar si tu app ya tiene pruebas y para crearlas.

Cómo usar esta guía

Corre un prompt a la vez, dentro de tu proyecto, para que la AI pueda leer tu código. Empieza por el primero, que te dice cómo estás hoy, y sigue en orden. No le pidas que escriba 200 pruebas de golpe: empieza por el flujo que te daría más problemas si se rompe.

Los 3 tipos de prueba

1. Unitarias o de componentes

Son pruebas pequeñas y rápidas que revisan una pieza sola: una función, un cálculo, un componente de la pantalla. Corren en segundos, así que las puedes correr todo el tiempo mientras construyes.

Ejemplo: que la función que calcula el total del carrito sume bien, incluyendo el descuento y el envío.

2. De integración

Revisan que varias piezas funcionen juntas. Aquí es donde aparecen los errores que no ves probando cada parte por separado.

Ejemplo: que el botón "agregar al carrito" de verdad añada el producto, actualice el contador y lo puedas ver en el carrito.

3. De principio a fin (E2E)

Simulan a un usuario real usando tu app completa, con todo conectado: interfaz, backend y base de datos.

Ejemplo: entrar a la app, añadir un producto, completar la compra y recibir el recibo.

Son las más lentas y las que más molestan cuando fallan sin motivo real, así que se hacen pocas: solo los flujos que te dan dinero o que, si se rompen, pierdes usuarios. Casi todo el mundo hace esta prueba a mano, abriendo la app y haciendo clic. Automatizarla es lo que casi nadie hace.

Regla simple

Muchas unitarias, algunas de integración, pocas E2E. Si solo vas a hacer una cosa hoy, automatiza el flujo principal de tu app de principio a fin.

1. ¿Mi app ya tiene pruebas?

Antes de crear nada, averigua qué tienes. Muchas apps hechas con AI traen un par de pruebas de ejemplo que no prueban nada real.

Actúa como un ingeniero de QA revisando un proyecto por primera vez.

Tu trabajo es decirme qué pruebas tiene hoy mi app y qué tan útiles son.

Esto es lo que tengo:
[PEGA AQUÍ el listado de archivos de tu proyecto y tu package.json, o abre este
prompt dentro de tu proyecto para que puedas leer el código]

Revisa:
1. Qué herramientas de prueba están instaladas y si están configuradas de verdad
2. Qué archivos de prueba existen y qué tipo son: unitarias, de integración o E2E
3. Si esas pruebas comprueban algo real o solo son ejemplos vacíos
4. Qué partes importantes de la app no tienen ninguna prueba
5. Si las pruebas se pueden correr con un comando y si pasan

Responde con este formato:
- Estado actual: en una frase
- Qué tengo: lista de lo que existe y si sirve
- Los 5 huecos más peligrosos: ordenados por lo que más duele si se rompe
- Por dónde empezar: un solo siguiente paso

No escribas pruebas todavía, solo dame el diagnóstico.

2. Qué probar primero

No todo vale lo mismo. Si tu app cobra, lo primero es el flujo del dinero.

Actúa como un ingeniero de QA que tiene que proteger una app con poco tiempo.

Tu trabajo es decidir qué se prueba primero en mi app.

Esto es lo que tengo:
[PEGA AQUÍ una descripción de tu app: qué hace, quién la usa, cómo gana dinero y
cuáles son las pantallas principales]

Haz esto:
1. Lista los flujos de usuario más importantes de mi app
2. Para cada uno dime qué pasaría si se rompe: pierdo dinero, pierdo usuarios,
   pierdo datos o solo molesta
3. Ordénalos por riesgo real, no por lo fácil que sea probarlos
4. Dime para cada uno qué tipo de prueba le conviene: unitaria, de integración
   o de principio a fin, y por qué
5. Propón un plan corto: qué probar esta semana y qué puede esperar

Responde en una tabla, y al final dime cuál es la primera prueba que debería
escribir hoy.

3. Preparar el entorno de pruebas

Si nunca has corrido una prueba, este es el paso que te desbloquea.

Actúa como un ingeniero de QA configurando pruebas en un proyecto desde cero.

Tu trabajo es dejarme listo para correr pruebas en mi proyecto.

Esto es lo que tengo:
[PEGA AQUÍ tu package.json y dime qué stack usas: Next.js, React Native, Expo,
Vue, Django, etc.]

Haz esto:
1. Recomiéndame las herramientas que mejor encajan con mi stack, una para
   pruebas unitarias y de integración y otra para pruebas de principio a fin
2. Explícame en una línea por qué esas y no otras
3. Dame los comandos exactos de instalación
4. Dame los archivos de configuración completos, listos para pegar
5. Dame los scripts que debo añadir a package.json para correrlas
6. Escribe UNA prueba mínima de ejemplo que pase, para confirmar que todo quedó
   bien conectado

Explícalo para alguien que nunca ha configurado pruebas. Dime también cómo sé
que funcionó y qué error común puede aparecer.

4. Pruebas unitarias o de componentes

Actúa como un ingeniero de QA escribiendo pruebas unitarias.

Tu trabajo es escribir pruebas pequeñas y rápidas para esta pieza de mi app.

Esto es lo que tengo:
[PEGA AQUÍ la función o el componente que quieres probar]

Haz esto:
1. Antes de escribir nada, lista qué debería hacer esta pieza, incluyendo los
   casos raros: valores vacíos, cero, negativos, textos largos, errores de red
2. Escribe las pruebas con la herramienta que ya usa mi proyecto
3. Cubre el caso normal, los casos raros y los casos de error
4. Usa nombres de prueba que expliquen el comportamiento esperado en español
5. Dime qué NO estás probando aquí y por qué

Al final dame el comando para correr solo estas pruebas.
No cambies el código de la función: si encuentras un bug, dímelo aparte.

5. Pruebas de integración

Actúa como un ingeniero de QA escribiendo pruebas de integración.

Tu trabajo es probar que varias piezas de mi app funcionan juntas.

Esto es lo que tengo:
[PEGA AQUÍ el flujo que quieres probar y el código de las piezas que participan:
componentes, estado, llamadas a la API]

Haz esto:
1. Explica qué piezas participan en este flujo y dónde suelen romperse
2. Escribe pruebas que comprueben el resultado que ve el usuario, no los
   detalles internos de la implementación
3. Simula las llamadas externas (API, base de datos, pagos) en vez de llamarlas
   de verdad, y muéstrame cómo
4. Incluye qué pasa cuando la API falla o tarda
5. Evita pruebas que se rompan solo porque cambié un nombre de clase o un texto

Al final dime qué parte de este flujo sigue sin estar cubierta.

6. Pruebas de principio a fin (E2E)

Esta es la que casi nadie automatiza. Empieza por un solo flujo, el más importante.

Actúa como un ingeniero de QA escribiendo pruebas de principio a fin.

Tu trabajo es automatizar el recorrido completo de un usuario real en mi app.

Esto es lo que tengo:
[PEGA AQUÍ el flujo paso a paso que quieres automatizar, por ejemplo: entrar,
buscar un producto, añadirlo al carrito, pagar y ver el recibo. Añade las URLs o
pantallas y cómo se hace login]

Haz esto:
1. Escribe la prueba con la herramienta de E2E de mi proyecto (si no tengo,
   recomiéndame una para mi stack y dame la configuración)
2. Cubre el camino feliz completo, de principio a fin
3. Añade las comprobaciones que de verdad importan: que el usuario vea la
   confirmación, que el pedido exista, que el total sea correcto
4. Usa selectores estables, no textos que cambian seguido
5. Explica cómo usar datos de prueba y cómo dejar el sistema limpio al terminar
6. Dime cómo evitar que esta prueba falle sin que haya un bug real

Importante: esta prueba debe correr contra un ambiente de pruebas, nunca contra
producción ni con datos de usuarios reales. Dime cómo asegurarme de eso.

7. Que la AI no rompa lo que ya funciona

Este es el prompt que convierte las pruebas en una red de seguridad mientras construyes con AI.

De ahora en adelante, trabaja así en este proyecto:

1. Antes de cambiar código, corre las pruebas y dime si pasan
2. Cuando añadas una función nueva, escribe también su prueba
3. Cuando arregles un bug, escribe primero una prueba que falle por ese bug,
   y luego arréglalo
4. Después de cada cambio, vuelve a correr todas las pruebas
5. Si una prueba que antes pasaba ahora falla, PARA y dime qué rompiste. No
   cambies la prueba para que pase

Confirma que entendiste estas reglas y dime cuál es el estado de las pruebas
ahora mismo.

8. Correr las pruebas solas en cada cambio

Actúa como un ingeniero de QA configurando integración continua.

Tu trabajo es que mis pruebas corran solas cada vez que suba cambios, para que yo
no tenga que acordarme.

Esto es lo que tengo:
[PEGA AQUÍ tus scripts de pruebas del package.json y dime dónde está tu
repositorio: GitHub, GitLab, etc.]

Haz esto:
1. Dame el archivo de configuración completo, listo para pegar
2. Que corra las pruebas unitarias y de integración en cada push y en cada pull
   request
3. Que las de principio a fin corran también, o explícame por qué conviene
   correrlas aparte
4. Explícame dónde veo el resultado y qué hacer cuando falla
5. Dime cómo manejar las claves y variables de entorno sin exponerlas

Explícalo para alguien que nunca ha configurado esto.

Importante

Las pruebas no sustituyen abrir tu app y usarla como un usuario. Lo que hacen es avisarte cuando algo que ya funcionaba dejó de funcionar, que es justo lo que más pasa cuando construyes con AI.