Suite de pruebas mínima para código generado por IA que se mantiene estable

Por qué el código generado por IA sigue rompiéndose después de arreglarlo

El código inestable generado por IA es ese que parece estar bien hasta que lo tocas. Arreglas un bug y se rompen dos pantallas no relacionadas. Un despliegue que funcionó ayer falla hoy. Pequeños cambios provocan grandes sorpresas porque el código tiene efectos secundarios ocultos y reglas poco claras.

En proyectos reales suele verse así:

• Un cambio en el login rompe la facturación porque ambos dependen de un helper a medias.
• Una respuesta de la API cambia de forma y la UI silenciosamente cae en estados vacíos.
• La autenticación funciona en local pero falla en producción por variables de entorno faltantes o secretos filtrados.
• Un refactor rápido provoca fallos aleatorios porque el estado se guarda en el lugar equivocado.

Esto es común en prototipos generados por IA porque el código se produce en fragmentos, no se diseña como un sistema. Los nombres se deslizan, los hacks temporales se vuelven dependencias y rara vez hay una red de seguridad. Los equipos acaban haciendo arreglos de emergencia una y otra vez. Es caro y estresante.

La forma más económica de detener la hemorragia es una pequeña suite de pruebas de alto valor. Las pruebas no son magia. Simplemente detectan roturas temprano, antes de que las vea el usuario. También te dan confianza para refactorizar y eliminar partes raras sin adivinar.

Tres tipos de pruebas dan la mayor protección con el menor esfuerzo:

• Pruebas smoke: ¿la app arranca básicamente?
• Pruebas de contrato de API: ¿las respuestas siguen siendo compatibles con la UI e integraciones?
• Pruebas de regresión: ¿un bug arreglado sigue arreglado?

El objetivo no es la cobertura del 100%. El éxito es más sencillo: puedes desplegar sin miedo, puedes cambiar código sin romper lo arreglado la semana pasada y las fallas señalan exactamente la característica que falló.

Elige qué proteger primero (el 20 % que causa el 80 % del dolor)

Si tu app fue generada por herramientas de IA, puede parecer que todo es frágil. Una suite mínima funciona mejor cuando protege los pocos caminos que la gente usa a diario, más los puntos donde un pequeño cambio puede romper cinco cosas.

Empieza listando los recorridos de usuario que más generan soporte cuando fallan. Sé práctico: ¿qué haría que el producto pareciera caído para un usuario real? Normalmente es login y registro (incluido reset de contraseña), checkout o cambios de suscripción, tu flujo central crear-editar-borrar, webhooks y subida/descarga de archivos.

Luego mira las integraciones más propensas a romperse de forma rara: pagos, envío de emails, proveedores de identidad y almacenamiento de archivos. No necesitas cobertura end-to-end completa. Quieres comprobaciones rápidas que prueben que aún puedes conectar y obtener una respuesta sensata.

Ahora elige sólo 3 a 5 endpoints o flujos que nunca deben fallar. Para un SaaS simple, podría ser: login, crear proyecto, invitar compañero, cancelar suscripción.

Antes de escribir una sola prueba, define qué significa “funcionar” para cada uno. Mantén la definición corta y medible:

• Código de estado esperado y un par de campos clave
• Forma de la respuesta (claves y tipos)
• Un efecto secundario clave (registro creado, email en cola, webhook enviado)
• Una regla de seguridad clave (no acceder a datos de otros usuarios)

Finalmente, elige un entorno de pruebas y mantente con él. Local está bien si el setup es consistente. Staging está bien si los datos están controlados. Mezclarlos es como convertir “mínimo” en ruido confuso.

Pruebas smoke: comprobaciones rápidas que detectan roturas obvias

Las pruebas smoke responden una pregunta tras cualquier cambio: ¿la app sigue arrancando y responden las rutas más importantes?

Una buena prueba smoke no intenta probar que todo sea correcto. Prueba que lo básico no esté totalmente roto. Por eso son una gran primera capa para proyectos escritos por IA y con inestabilidad.

Qué incluir

Elige unos cuantos objetivos que representen “la app está viva” y “los usuarios pueden hacer lo principal”. Por ejemplo:

• Un health check devuelve 200 (o la página principal carga)
• La página de login se renderiza (o el endpoint de auth responde)
• Una API central devuelve el estado esperado (como obtener el usuario actual o una lista principal)
• La conexión a la base de datos puede abrirse (solo si esto falla con frecuencia)

Mantén cada prueba corta. Apunta a una aserción clara por prueba, como “devuelve 200” o “la respuesta incluye userId.” Cuando una smoke test falla, quieres que la razón sea obvia.

Cómo mantenerlas rápidas y fiables

Pon un presupuesto estricto: menos de 1 a 2 minutos en total. Las pruebas smoke deben ejecutarse constantemente, no “cuando alguien se acuerda”. Una rutina simple funciona bien:

• Ejecutar las smoke tests localmente antes de hacer push
• Ejecutarlas automáticamente en cada pull request
• Bloquear merges si fallan

Ejemplo: arreglaste un flujo de auth que devolvía 500s aleatorios. Añade una smoke test que se autentique con una cuenta de test y luego haga GET /me. Si vuelve a romperse, lo sabrás de inmediato.

Pruebas de contrato de API: mantener las respuestas estables para la UI e integraciones

Las pruebas de contrato verifican que un endpoint cumple su promesa: qué campos aparecen, qué tipos son y qué formato de error puede esperar el cliente. No intentan probar toda la lógica de negocio. Previenen una de las fallas más comunes en código que cambia rápido: un cambio backend que rompe silenciosamente la UI o una integración.

Para una suite mínima, elige solo los endpoints que más daño causarían si cambiasen. Normalmente son unas pocas llamadas que la UI hace en cada carga de página, además de cualquier cosa de la que dependa un sistema externo.

Una forma simple de elegir es mirar la pestaña de red y los logs de errores, luego bloquear 2 a 3 endpoints críticos de contrato, como:

• Login o comprobación de sesión ("¿estoy conectado?")
• Perfil del usuario actual ("¿quién soy?")
• La acción central de creación ("crear pedido", "guardar borrador", "publicar mensaje")
• Un endpoint de lista crítico ("mis proyectos", "mis facturas")

Cubre tanto éxito como fallo. Muchas apps inestables fallan en rutas aburridas: cabeceras de auth faltantes, input inválido, sesiones expiradas.

Qué asertar (y qué ignorar)

Bloquea solo las partes estables. Aserta cosas con las que una persona pueda leer y estar de acuerdo. Omite campos volátiles que cambian en cada ejecución.

• Campos requeridos existen (id, email, status) y los tipos tienen sentido
• Las respuestas de error siempre tienen la misma forma (code, message) y el status HTTP correcto
• Los arrays son arrays, no a veces null
• Ignora timestamps, IDs aleatorios y el orden salvo que el orden sea parte de la promesa

Escribe expectativas en lenguaje claro para que un fundador no técnico pueda verificarlas. Ejemplo: “Si falta auth, /me devuelve 401 con { code, message }. Si auth es válida, devuelve 200 con { id, email }.” Esa regla sola evita mucho retrabajo.

Pruebas de regresión: convertir arreglos en protecciones permanentes

Las pruebas de regresión son las pruebas de “este bug nunca debe volver”. En codebases generados por IA, los arreglos pueden desaparecer la próxima vez que alguien cambia un prompt, regenera un archivo o refactoriza una función desordenada. Una pequeña suite de regresión hace que tus arreglos perduren.

El mejor momento para añadir una prueba de regresión es justo después de arreglar el bug, mientras el fallo sigue fresco. Semanas después olvidarás los inputs exactos y el impacto real en el usuario.

Mantén cada prueba de regresión enfocada en la reproducción más pequeña. Captura solo lo necesario: los inputs específicos, los pocos pasos que desencadenan el bug y el resultado esperado. Si el bug antiguo requería diez pantallas de setup, eso es señal de que necesitas una mejor seam de pruebas, no una prueba más grande.

Un patrón simple:

• Recrea la petición o acción de usuario que fallaba en una prueba.
• Aserta el comportamiento incorrecto exacto que ocurría (código de estado, mensaje de error, datos erróneos).
• Aplica la corrección.
• Actualiza la aserción al comportamiento correcto y mantenla precisa.
• Nombra la prueba para que el tú del futuro entienda el coste de romperla.

Los nombres de pruebas son documentación infrautilizada. Un buen nombre incluye qué falló y por qué importa, por ejemplo: rejects_login_when_token_is_missing_prevents_account_takeover.

Ejemplo concreto: arreglaste un bug del restablecimiento de contraseña que filtraba si existía un usuario. La prueba de regresión debería enviar una petición de reset para un email inexistente y asertar que la respuesta sigue siendo genérica y consistente.

Paso a paso: construir una suite mínima en una sesión enfocada

Haz que las pruebas sean fáciles de encontrar y aburridas de ejecutar. Crea una pequeña estructura y una regla de nombres que seguirás dentro de un mes:

• tests/smoke/ para comprobaciones de “¿arranca siquiera?”
• tests/contracts/ para chequear formas de respuesta de la API
• tests/regression/ para bugs que ya arreglaste

Nombra archivos por característica (por ejemplo: auth, users, billing) para que la gente encuentre las pruebas rápido.

Luego, añade un puñado de pruebas que te den confianza rápida. Mantén el setup simple para que se ejecuten igual en todas las máquinas. Un buen punto de partida es:

• 3 pruebas smoke (arranque, un flujo principal, una API crítica)
• 2 pruebas de contrato (tus dos endpoints más usados)
• 2 pruebas de regresión (tus dos últimos incidentes reales)

Cuando escribas smoke tests, piensa como un usuario cansado: “abro la app, hago lo principal, funciona.” Cuando escribas pruebas de contrato, piensa como front-end: “necesito id, name y role, no un renombrado sorpresa.” Cuando escribas pruebas de regresión, copia los pasos exactos que fallaron en producción y aserta el comportamiento corregido.

Ejecuta todo localmente primero y luego ejecuta el mismo comando en tu pipeline de despliegue. Si las pruebas son demasiado lentas, reduce el alcance, no la precisión.

Una regla mantiene la suite viva: si tocas una funcionalidad, añade o actualiza una prueba para ella.

Hacer las pruebas fiables: datos estables, setup estable, limpieza estable

Una suite mínima solo ayuda si da la misma respuesta en cada ejecución. La mayoría de las “fallas aleatorias” no son aleatorias. Vienen de datos compartidos, setup inconsistente o pruebas que dependen de servicios externos.

Mantén los datos de prueba separados de los reales. Usa una base de datos de test, un esquema temporal o un dataset desechable que pueda borrarse con seguridad. Si las pruebas pueden tocar datos de producción, terminarán corrompiéndolos o dando miedo ejecutarlas.

Haz que el setup sea predecible. Crea unos pocos usuarios y roles conocidos y reutilízalos: un admin, un usuario normal y un usuario bloqueado. Mantén sus credenciales fijas en la configuración de pruebas para no perseguir cambios después.

Los servicios externos son una fuente común de inestabilidad. Si las pruebas golpean email real, pagos o webhooks, verás timeouts, límites de tasa y fallos sorpresa. Finge esas llamadas cuando puedas, o stubéalas para que solo pruebes “enviamos la solicitud correcta” y “manejamos la respuesta”.

Los fixtures ayudan a evitar datos copiados que se desvían. Mantén un pequeño conjunto de builders para objetos comunes como usuario, proyecto u orden. Usa valores por defecto claros y sobreescribe solo lo que una prueba necesita.

Resetea el estado entre pruebas para que una falla no envenene la siguiente. Un bucle simple es: crear datos, ejecutar la acción, asertar lo importante y luego limpiar (rollback o truncar tablas) y resetear caches/flags.

Errores comunes que hacen perder tiempo y crean pruebas inestables

La forma más rápida de quedarse sin pruebas es intentar probarlo todo a la vez. Si apuntas a cobertura total en el día uno, te quedarás atascado en wiring de setup, luchando con fallos y nunca enviarás una suite usable.

Otra trampa es probar lo incorrecto. Chequeos de UI pixel-perfect y coincidencias exactas de texto parecen tranquilizadores, pero se rompen por cambios inocuos como una etiqueta nueva en un botón. Las pruebas mínimas deben centrarse en resultados: “usuario puede iniciar sesión”, “total de la factura es correcto”, “la API devuelve los campos que la UI necesita”.

Las pruebas también se vuelven inestables si dependen de internet. APIs reales de pago, email o analytics fallan, se limitan por tasa o cambian respuestas. Stubéalas y reserva una comprobación end-to-end ocasional para staging, no cada commit.

Vigila aserciones frágiles. IDs, timestamps y mensajes autogenerados cambian constantemente en prototipos desordenados. Prefiere comprobaciones estables como códigos de estado, campos clave y patrones simples (por ejemplo, “createdAt existe y es una fecha ISO”) en lugar de coincidir con la cadena de timestamp exacta.

Si lidias con flakiness, estas correcciones suelen ayudar rápido:

• Probar resultados, no pixeles de UI ni texto exacto
• Stubear APIs de terceros y controlar las respuestas
• Evitar aserciones sobre IDs aleatorios y timestamps exactos
• Añadir al menos una prueba de ruta de error por endpoint crítico
• Mantener la suite rápida (minutos, no decenas de minutos)

No ignores las rutas de error. Las apps generadas por IA suelen fallar en sesiones expiradas, variables de entorno faltantes y payloads malformados. Si solo pruebas caminos felices, seguirás rompiendo características “arregladas”.

Checklist rápido: ¿tu suite mínima hace su trabajo?

Una suite mínima solo es mínima si protege lo que envías y sigue rápida para ejecutarse siempre.

La suite protege lo básico

Si cualquiera de estos falla, la app no es segura para desplegar:

• La app arranca limpiamente (sin variables de entorno faltantes, sin crash al boot).
• La configuración de la base de datos funciona (migraciones corren en una BD fresca).
• Una página o pantalla clave se renderiza (a menudo el dashboard).
• Tus 3 APIs principales devuelven los campos que la UI espera (nombres y tipos que realmente usas).
• Esas mismas APIs devuelven formas de error consistentes (para que la UI muestre un mensaje útil).

La suite sigue fácil de ejecutar y de confiar

Velocidad y repetibilidad importan más que volumen:

• Los dos últimos bugs críticos que arreglaste tienen test de regresión.
• Las pruebas terminan en pocos minutos en un portátil normal.
• Una persona puede ejecutar todo con un solo comando, sin conocimiento tribal.

Cuando una prueba falla, deberías aprender algo de inmediato. Una buena falla apunta a una causa probable (“token de login faltante”, “campo de la API renombrado”), no a un timeout vago.

Ejemplo: proteger un flujo de auth arreglado para que no vuelva a romperse

Una historia común: un fundador lanza un prototipo hecho con IA con login y suscripciones. Funciona en demos, pero usuarios reales encuentran fallos raros. Los logins vuelven a la pantalla de inicio, las sesiones expiran al instante y el checkout falla porque la app cree que el usuario está desconectado.

Alguien repara la lógica de autenticación, limpia cookies o tokens y la app finalmente mantiene la sesión. Dos semanas después, cae un cambio pequeño (a menudo en otra parte del codebase) y el login vuelve a romperse. Nadie tocó “auth”, pero un middleware nuevo, un refactor o un cambio de entorno modifica el comportamiento.

Una suite mínima evita este rebote poniendo tres pequeñas guardas alrededor del flujo:

• Una smoke test que toque la ruta de login y verifique una señal clara de éxito (200 OK más una cookie de sesión o token presente).
• Una prueba de contrato que verifique la forma de la respuesta del endpoint de sesión (por ejemplo: user id, email, subscription status), para que la UI no se rompa cuando los campos se muevan o renombren.
• Una prueba de regresión que reproduzca el bug exacto que viste, como “después de login, GET /me devuelve 401” o “refrescar la página pierde la sesión.”

Mantén las comprobaciones simples. No intentas cubrir cada caso borde. Proteges lo que paga las cuentas: que la gente pueda iniciar sesión y permanecer conectada.

El beneficio aparece la próxima vez que alguien cambia código. En lugar de usuarios reportando “no puedo iniciar sesión”, la build falla rápido con un mensaje como “falta subscriptionStatus en la respuesta de sesión.” Es un arreglo de cinco minutos, no una búsqueda de varios días.

También reduce idas y vueltas con contratistas y agencias. Ya no discutes si auth funciona en una máquina: la prueba es el árbitro.

Siguientes pasos: mantener la suite mínima y seguir lanzando con seguridad

Una suite mínima solo funciona si se mantiene ligada al dolor real. El objetivo no es “más cobertura”. El objetivo es menos sorpresas tras cada cambio.

Elige tus siguientes cinco tests según lo que realmente te costó tiempo: tickets de soporte, outages y las partes de la app que temes tocar. Saca los tres últimos fallos de producción (o casi fallos) y convierte cada uno en una prueba de regresión que falle igual que falló en la vida real.

Para mantener el impulso sin que las pruebas te ocupen la semana:

• Tras cada arreglo, añade 1 pequeña prueba de regresión que demuestre que el arreglo se mantiene.
• Tras cada incidente, añade 1 prueba smoke que lo habría detectado rápido.
• Cada dos semanas, añade 1 prueba de contrato para tu endpoint o integración más usada.
• Mantén una lista corta de “puntos críticos” y retira pruebas que ya no reflejen los riesgos actuales.
• Para cuando las nuevas pruebas dejan de encontrar problemas reales, ahí está tu conjunto mínimo.

Si el codebase es un desastre, ampliar las pruebas demasiado rápido puede ser contraproducente. Cuando el setup es impredecible, obtienes pruebas inestables que la gente ignora. En ese caso, haz una pasada corta de estabilización primero: crea una ruta limpia para arrancar la app, monta una configuración de base de datos de pruebas fiable y elimina peligros obvios como secretos expuestos o estado global frágil.

Si heredaste un prototipo generado por IA que sigue regresando, FixMyMess (fixmymess.ai) se especializa en diagnosticar y reparar codebases creados por IA, y luego añadir justo las pruebas smoke, de contrato y de regresión necesarias para que los arreglos no se deshagan tras el siguiente cambio.

Trata tu suite como un cinturón de seguridad: pequeña, siempre puesta y enfocada en los choques que ya tuviste.