Las pruebas automatizadas revelan código SaaS con IA recuperable

Las pruebas automatizadas pueden decirte si vale la pena recuperar un SaaS creado con IA, pero solo si miden las reglas de negocio que hacen que merezca la pena operarlo. Cien pruebas de componentes en verde no responden si un cliente puede pagar una sola vez, ver únicamente sus propios registros, superar un reintento y recibir la misma aplicación tras un despliegue limpio.

He visto a equipos tomar una batería de pruebas generada como un voto de confianza en código también generado. Eso invierte la carga de la prueba. El código existente no gana puntos por ser fácil de probar. Se gana el presupuesto de reparación cuando produce un conjunto pequeño y repetible de evidencias sobre ingresos, autoridad, datos y comportamiento de las versiones.

Esas evidencias deben ser lo bastante pequeñas para que una persona fundadora las entienda y lo bastante estrictas para que una persona técnica desconfíe de ellas. También deben fallar por motivos útiles. Si cada prueba fallida acaba en un tiempo de espera sin explicación, habrás aprendido poco sobre el sistema. Si una prueba indica que un segundo webhook creó un segundo pedido pagado o que un miembro leyó la factura de otro cliente, ha expuesto tanto un defecto como el límite de la reparación.

El objetivo no es demostrar que el SaaS no tiene errores. Ninguna batería práctica de pruebas lo demuestra. El objetivo es decidir si el comportamiento valioso del producto puede aislarse, especificarse, repararse y desplegarse sin pagar por redescubrir la aplicación pantalla a pantalla.

Una batería en verde solo sirve si protege una regla

Una prueba superada importa cuando puedes nombrar la promesa que protege, el fallo que detectaría y el artefacto que deja para revisión. Sin esas tres partes, un resultado verde suele ser puro trámite.

Los creadores de aplicaciones con IA suelen generar pruebas sobre el comportamiento visible porque resulta fácil de describir: una página carga, un botón responde, una ventana se cierra. Esas pruebas pueden detectar regresiones, pero dicen muy poco sobre si el código tiene un modelo de dominio coherente. Una página de pago puede mostrar un mensaje de éxito mientras el controlador del webhook crea suscripciones duplicadas. Un botón de administración puede desaparecer mientras su endpoint acepta la petición de un miembro. Un formulario puede mostrar la nueva dirección mientras la base de datos solo guardó una parte.

Usa un conjunto de evidencias con cuatro partes. Cada una responde a una pregunta distinta sobre la recuperación:

• Flujos de ingresos: ¿puede el estado relacionado con el dinero avanzar exactamente una vez, incluidos reintentos y fallos?
• Permisos: ¿impone el servidor los límites de rol y cliente tanto para acciones permitidas como prohibidas?
• Integridad de datos: ¿siguen siendo válidas las escrituras ante fallos parciales, concurrencia y peticiones repetidas?
• Repetibilidad del despliegue: ¿puede un entorno vacío convertirse en una versión operativa mediante una única ruta documentada?

La diferencia entre una batería de regresión y una de recuperación importa. Una batería de regresión protege comportamientos conocidos después de que el equipo confía en la arquitectura. Una batería de recuperación descubre si existe suficiente comportamiento estable para justificar la reparación de una arquitectura en la que nadie confía aún. Puedes reutilizar pruebas existentes, pero las aserciones heredadas no merecen un trato especial. Vincula cada una con una regla o quítala del conjunto de decisión.

El Estándar de Verificación de Seguridad de Aplicaciones de OWASP ofrece una separación útil. Tiene áreas distintas para autenticación, control de acceso, lógica de negocio, protección de datos, API y configuración. Esa estructura funciona mejor que afirmar de forma genérica que la aplicación es «segura», pero aplicar todos los requisitos de ASVS antes de decidir una recuperación enterraría la decisión bajo demasiado trabajo. Usa los requisitos pertinentes para precisar las pruebas de límites y mantén el conjunto de aprobación ligado a los riesgos reales del producto.

Un buen nombre de prueba parece una política. second_paid_webhook_does_not_create_another_entitlement dice más que payment_test_03. Cuando una persona sin conocimientos técnicos lea el informe, el nombre debe decirle qué resistió y qué no.

Define la decisión antes de reparar el código

Escribe el umbral de recuperación antes de que nadie arregle la primera prueba fallida. De lo contrario, cada reparación cambia el criterio y el coste ya invertido empieza a dirigir la decisión.

El umbral necesita resultados, evidencias y condiciones de parada. No necesita una previsión basada en estimaciones técnicas inventadas. Para cada área de evidencia, registra un recorrido crítico, el estado que debe mantenerse, la prueba observable y el resultado que detendría la reparación. Conserva ese documento junto a las pruebas para que quienes revisen puedan distinguir un fallo de negocio de un fallo del sistema de pruebas.

Un archivo compacto puede contener el contrato:

salvage_gate:
  revenue:
    journey: paid checkout plus duplicate webhook
    invariant: one charge maps to one entitlement
    proof: order row, entitlement row, provider event id
    stop_if: duplicate processing cannot be made atomic
  permissions:
    journey: member requests another tenant's invoice
    invariant: server denies the request without revealing existence
    proof: 404 response and unchanged audit record
    stop_if: tenant ownership is absent from the data model
  data_integrity:
    journey: two workers claim the same queued job
    invariant: one worker owns the job
    proof: one claim token and one completed result
    stop_if: authoritative state exists only in browser storage
  deployment:
    journey: empty environment to smoke-tested release
    invariant: migrations and configuration are deterministic
    proof: commit id, migration log, smoke-test report
    stop_if: production requires an undocumented manual edit

La sintaxis exacta no importa. La precisión sí. «Los pagos funcionan» permite que el equipo de reparación muestre la ruta más fácil. «Un webhook de pago duplicado deja un único derecho de acceso» obliga a que la prueba atraviese un límite de fallo habitual y produce un estado que se puede inspeccionar.

Elige condiciones de parada que expongan cimientos ausentes, no defectos corrientes. Un condicional incorrecto puede repararse. Si ninguna tabla contiene la propiedad del cliente, una reparación pequeña puede convertirse en una reconstrucción del modelo de datos. Una migración que falla por un valor predeterminado incorrecto es una tarea acotada. Si el esquema de la base de producción difiere de todos los archivos de migración, el repositorio no es la fuente de verdad.

Fija un plazo para reunir evidencias, pero no conviertas el tiempo transcurrido en el veredicto. Un entorno de pruebas lento puede decir más sobre la repetibilidad del despliegue que sobre la calidad del código. Registra las pruebas bloqueadas por separado de las superadas y fallidas. Una prueba de ingresos bloqueada porque nadie conoce el secreto del webhook es evidencia sobre el despliegue, no una omisión neutral.

El resultado de la aprobación debe tener uno de tres estados: reparar, reconstruir un subsistema acotado o detenerse y redefinir el producto. Evita una puntuación porcentual única. Las puntuaciones ocultan vetos. Un producto puede superar nueve comprobaciones menores y seguir siendo inseguro porque falla el aislamiento entre clientes.

Las pruebas de ingresos deben seguir el estado

Una prueba de ingresos debe demostrar la transición completa del estado comercial, incluidos los caminos incómodos después de que el navegador informa del éxito. El navegador es un participante de esa transacción y normalmente no es la autoridad.

Empieza con el recorrido más pequeño que crea o conserva ingresos: un cliente inicia el pago, el proveedor confirma un evento, la aplicación registra la compra y el cliente recibe el derecho correcto. Después ejecuta de nuevo el mismo evento del proveedor. La segunda entrega debe producir el mismo estado de negocio sin un segundo pedido, crédito, registro de correo ni derecho.

No des por terminada la prueba cuando reciba un estado de éxito. Recoge evidencias de cada límite que actúa como autoridad:

• El identificador del evento del proveedor se guarda bajo una regla de unicidad.
• El pedido y el derecho se refieren al mismo cliente y organización.
• Un reintento devuelve un resultado estable en vez de repetir efectos secundarios.
• Una acción posterior fallida puede reanudarse sin repetir la transición relacionada con el cobro.
• Un reembolso o una cancelación elimina solo el acceso que establece la política del producto.

Aquí es donde las aplicaciones generadas suelen revelar una autoridad dividida. El navegador escribe una marca paid=true, una función sin servidor escribe un pedido y un webhook escribe una suscripción. Cada ruta parece razonable por separado. Juntas permiten estados contradictorios. Las pruebas automatizadas solo exponen la división cuando hacen aserciones sobre los tres almacenes e identifican qué registro posee la verdad.

Recorre un fallo con detalle. Envía el evento evt_test_42 y fuerza el fallo de la inserción del derecho después de insertar el pedido. Reintenta el mismo evento sin el fallo provocado. El resultado aceptable es un pedido y un derecho asociados con evt_test_42. Dos pedidos revelan que falta idempotencia. Un pedido sin derecho revela una brecha de transacción o recuperación. Un reintento rechazado para siempre muestra que el código marca el evento como completo demasiado pronto.

El informe debe mostrar una salida con forma de negocio en vez de un muro de aserciones:

REVENUE_GATE duplicate_webhook
provider_event=evt_test_42
orders=1 entitlements=1 notifications=1
first_attempt=rolled_back retry=completed
result=PASS

No uses una tarjeta real ni dependas de una cuenta de producción para probar la recuperación. Usa el modo de pruebas del proveedor o un adaptador controlado, pero mantén en la ruta la persistencia y la lógica de idempotencia reales de la aplicación. Simular todo el límite de pago solo demuestra que la simulación coincide consigo misma.

Una recomendación popular es empezar con pruebas de extremo a extremo para cada plan de precios. Parece completa y genera informes impresionantes. Es la primera inversión equivocada si el modelo de estado de ingresos puede estar roto. Demuestra un plan representativo mediante reintentos, cancelaciones y recuperación de fallos. Añade amplitud cuando la transición de estado tenga un único dueño.

Los permisos exigen dos clientes y negativas deliberadas

Las pruebas de permisos deben demostrar que el servidor rechaza el acceso prohibido incluso cuando quien llama evita la interfaz. Ocultar un botón es lógica de presentación, no autorización.

Crea dos clientes con datos de prueba estables. Asigna al primero una persona propietaria y un miembro; entrega al segundo un registro con un identificador que el primero pueda adivinar u obtener. Ejecuta peticiones directas contra lecturas y escrituras. El miembro del primer cliente no debe leer, actualizar, borrar, exportar ni adjuntar datos al registro del segundo.

Prueba también las acciones permitidas. Una batería formada solo por negativas puede superarse porque todos los endpoints están rotos. Cada operación protegida necesita una aserción emparejada: el rol correcto tiene éxito con su propio objeto, mientras el rol o cliente equivocado falla en la misma ruta. Comprueba la base de datos tras ambas peticiones. Un servidor que devuelve 403 después de realizar la escritura sigue comprometido.

Decide si la aplicación usa 403 o 404 para objetos de otros clientes y aplica la regla con coherencia. Devolver 404 suele evitar confirmar que existe el registro de otro cliente. El estado por sí solo no basta. Compara la forma de la respuesta, el tiempo dentro de una tolerancia razonable y los efectos secundarios para que un controlador de errores no filtre un título, el nombre del dueño o una ruta de almacenamiento.

OWASP ASVS trata el control de acceso y la lógica de negocio como áreas de verificación separadas, y eso constituye una advertencia útil. Una persona puede tener permiso para emitir un reembolso y aun así incumplir una regla al reembolsar dos veces el mismo pago o aprobar su propia solicitud. Las comprobaciones de rol responden «¿puede este actor llamar a la operación?». Las reglas de negocio responden «¿puede esta operación válida cambiar este objeto ahora?». Una batería de recuperación necesita ambas.

El código generado suele dispersar cadenas de roles por controladores de rutas, condiciones de interfaz y consultas a la base de datos. No refactorices de inmediato esas cadenas para crear una capa de políticas elegante. Usa primero las pruebas para saber dónde se aplica realmente el control. Si un límite del servidor puede convertirse en autoridad, la reparación puede estar acotada. Si cada consulta confía en un tenantId enviado por el cliente, calcula una reparación más profunda.

Trata los roles de servicio y los trabajos en segundo plano como actores de la misma matriz. Un trabajador de cola con credenciales de base de datos sin restricciones puede borrar las garantías probadas mediante la API pública. Dale a una operación en segundo plano un elemento de prueba de cada cliente y verifica que tanto la consulta de selección como la actualización conserven la propiedad.

Una negativa fallida veta la aprobación para producción, pero no siempre veta la recuperación. La pregunta de diagnóstico es si el modelo de datos contiene los datos de propiedad necesarios para aplicar la negativa. Si cada factura tiene una referencia fiable al cliente, la reparación tiene una base. Si la propiedad debe inferirse a partir de direcciones de correo mutables, la prueba ha encontrado un límite de reconstrucción.

La integridad aparece cuando las peticiones chocan

Las pruebas de integridad de datos deben forzar la aplicación hacia estados que las pruebas de camino feliz evitan educadamente. Los reintentos, escrituras concurrentes, cierres de procesos y fallos parciales posteriores revelan si la base de datos protege las reglas del producto o solo guarda lo que envía la aplicación.

Empieza por escribir cada regla importante como un hecho de la base de datos. Un token de invitación puede consumirse una vez. Un correo pertenece como máximo a una cuenta activa dentro del ámbito elegido. Un trabajo tiene un propietario actual. El total de una factura coincide con las líneas guardadas según la regla de redondeo del producto. Después busca la capa más baja que pueda imponer cada hecho. Prefiere una restricción de unicidad, una clave externa, una comprobación o una transacción cuando la base de datos pueda expresar la regla.

Las comprobaciones de aplicación como «consultar primero e insertar si no existe» son vulnerables cuando dos peticiones se ejecutan juntas. Una prueba determinista de concurrencia hace visible la carrera: pausa ambas peticiones después de observar la ausencia, libéralas a la vez e inspecciona las filas finales. Si la restricción de la base de datos rechaza una inserción y la aplicación convierte el rechazo en la respuesta esperada, la regla se mantiene. Si aparecen dos filas, repetir la prueba no sustituye a una restricción.

La documentación de PostgreSQL explica que el aislamiento de transacciones controla qué cambios concurrentes puede ver una transacción. Los equipos suelen citar niveles de aislamiento como si elegir una etiqueta más fuerte resolviera cada carrera. No es así. La aplicación todavía necesita un límite de transacción correcto, restricciones y una respuesta deliberada ante fallos de serialización o unicidad. Un controlador generado que inicia una transacción después de su primera escritura ya ha perdido el límite útil.

Prueba la recuperación como estado, no solo como código de error. Detén un trabajador después de que reclame un trabajo pero antes de registrar que terminó. Avanza el tiempo de la concesión o recuperación mediante un reloj inyectado, inicia otro trabajador y verifica que existe un único resultado final. Esto distingue la entrega al menos una vez, que permite intentos repetidos, de los efectos de negocio duplicados que la aplicación debe evitar.

No compares instantáneas completas de la base de datos en cada caso. Esas pruebas hacen que campos inocuos parezcan importantes y esconden la regla entre el ruido. Consulta los registros que determinan la decisión e imprime una diferencia compacta del antes y el después. Haz deterministas las marcas de tiempo, los identificadores aleatorios y el orden generado cuando el comportamiento lo permita.

Si las pruebas requieren scripts globales de limpieza que borren tablas entre casos, inspecciona esa dependencia. Puede ocultar filtros de cliente ausentes y dependencia del orden. Un mejor conjunto de prueba crea identificadores de cliente aislados, se ejecuta con seguridad junto a otro conjunto y elimina solo sus propios registros. Los fallos de pruebas en paralelo suelen ser evidencias de arquitectura disfrazadas de problema del ejecutor.

Los fallos de integridad definen el tamaño de la reparación. Las restricciones ausentes alrededor de un esquema coherente suelen ser reparables. Varios identificadores enfrentados para el mismo usuario, bloques serializados sin versión o estado de negocio guardado solo en el navegador apuntan hacia una reconstrucción acotada. Registra ese límite en vez de añadir más preparación de pruebas para imitar coherencia.

Un despliegue repetible empieza desde cero

La repetibilidad del despliegue significa que un comando documentado puede convertir un entorno limpio y una configuración declarada en la misma aplicación probada. Volver a desplegar la máquina de producción que ya funciona no lo demuestra.

Usa una base de datos vacía y un entorno de ejecución recién creado. Fija la revisión del código y el archivo de bloqueo de dependencias. Proporciona la configuración mediante el mecanismo documentado, ejecuta cada migración en el orden del repositorio, compila la aplicación, iníciala y ejecuta un recorrido básico de cada área de evidencia. Guarda juntos el registro de migración, la salida de compilación, el identificador de versión y los resultados de las pruebas básicas.

La primera ejecución importa, pero la segunda detecta la repetibilidad oculta. Destruye el entorno y repite el proceso con la misma revisión. Compara el estado del esquema, los datos de referencia iniciales, los recursos generados y la configuración observable. Una versión que solo funciona después de que alguien abre una consola y edita una fila ha fallado aunque al final responda.

No copies secretos de producción en la prueba. La evidencia necesaria es que cada secreto obligatorio tiene un nombre declarado, una fuente responsable y un modo de fallo cuando falta. Una comprobación de inicio debe identificar la configuración ausente antes de servir tráfico. Un secreto incluido en el código es un defecto de seguridad y evidencia de que los entornos no pueden recrearse de forma segura.

La documentación de GitHub Actions dice que las reglas de protección de entornos pueden bloquear un trabajo y ocultar los secretos del entorno hasta que se aprueben las reglas. Es un control de versión útil, pero no puede reparar una compilación irrepetible. Pide aprobación después de que el proceso haya creado evidencias inspeccionables. Una aprobación manual antes de scripts opacos solo formaliza una conjetura.

La documentación de Playwright recomienda grabar trazas en el primer reintento de las pruebas fallidas en integración continua. Coincido con la intención porque una traza puede conservar capturas, instantáneas del DOM y actividad de red de un fallo intermitente del navegador. Para una puerta de recuperación, conserva también los artefactos del primer fallo y nunca permitas que un reintento sustituya el resultado original. Una prueba que falla una vez y pasa al reintentar ofrece evidencia inestable, no limpia.

Incluye la recuperación de la versión anterior en la prueba de lanzamiento cuando las migraciones puedan cambiar datos de clientes. Quizá descubras que recuperarse significa desplegar hacia delante código compatible en vez de revertir una migración destructiva. Eso es aceptable si el manual lo dice y la prueba lo demuestra. Una migración down imaginaria es peor que un plan sincero de recuperación hacia delante.

Los fallos de despliegue suelen resolver la decisión más rápido que las quejas de estilo. Si el repositorio contiene su esquema, entradas de compilación y contrato de configuración, el equipo puede reparar hacia una versión conocida. Si el único sistema operativo depende de cambios en consola, funciones sin registrar y el entorno local de una persona, calcula primero la investigación. El archivo de código no es todo el producto.

La forma del fallo revela el límite de reparación

El patrón de fallos importa más que la cantidad. Diez fallos causados por un límite de autorización ausente pueden ser más baratos y seguros de reparar que dos causados por fuentes de verdad contradictorias.

Clasifica cada fallo por responsabilidad. Un fallo localizado tiene un componente responsable y un registro con autoridad. Un fallo transversal pasa por varias capas pero conserva un dueño claro. Un fallo de cimientos no tiene un dueño fiable, como el estado de una suscripción controlado de forma independiente por el navegador, una tabla de webhooks y una modificación administrativa sin regla de precedencia.

Después inspecciona el determinismo. Un fallo determinista es un activo porque el equipo puede reproducirlo y demostrar la reparación. Un fallo intermitente necesita artefactos que revelen planificación, estado, entradas y entorno. Si el equipo puede convertir una carrera intermitente en determinista mediante barreras o un reloj inyectado, el sistema resulta más recuperable incluso antes de cambiar el código de producción.

No premies los arreglos fáciles durante la evaluación. Resulta tentador corregir errores de sintaxis, actualizar dependencias y ajustar selectores porque la cifra de pruebas superadas sube rápido. Esos cambios pueden esperar salvo que desbloqueen un recorrido crítico. La decisión necesita primero información sobre la incertidumbre cara.

Usa un registro corto de reparación con cuatro campos: regla fallida, autoridad sospechada, límite mínimo de reparación y prueba necesaria después del arreglo. Evita las estimaciones hasta que la autoridad sospechada resulte creíble. «Arreglar el servicio de facturación» no es un límite cuando la verdad vive en cuatro tablas y dos almacenes del navegador. «Hacer únicos los identificadores de eventos procesados y confirmar el derecho en la misma transacción» es suficientemente comprobable para estimarlo.

El sistema de pruebas también puede fallar la evaluación. Las señales incluyen datos de prueba que llaman a producción, aserciones que dependen de la hora actual, reintentos que borran fallos, cuentas compartidas entre casos y simulaciones que duplican la implementación. Repara el sistema solo hasta obtener evidencias fiables. Un marco de pruebas impecable alrededor de un producto incoherente sigue siendo coste perdido.

La decisión es favorable cuando los fallos se agrupan alrededor de pocos límites, el modelo de datos contiene los hechos necesarios para aplicar las reglas y los despliegues limpios reproducen los mismos resultados. Es desfavorable cuando cada prueba exige una interpretación nueva del estado de negocio. Ese patrón significa que la reparación incluiría redescubrir la especificación del producto mientras se cambia.

La aprobación necesita vetos y dueños

Aprueba la reparación cuando cada área crítica de evidencia supera las pruebas o tiene un fallo acotado con un dueño identificado, un plan de reparación y una prueba que demostrará el cambio. No la apruebes por una tasa de éxito agregada.

La duplicación de ingresos, el acceso entre clientes, la corrupción irrecuperable de datos y un entorno de producción imposible de recrear merecen un veto explícito. Un veto puede llevar a reconstruir un subsistema en vez de cancelar, pero alguien debe nombrar ese alcance antes de empezar. Si el equipo no puede acordar qué estado tiene autoridad, el alcance no está listo para un compromiso cerrado.

Pide un paquete de evidencias, no una presentación. Debe contener el archivo de puerta de recuperación, la revisión exacta, el comando de pruebas, la descripción de los datos de prueba, los artefactos del primer fallo, diferencias de base de datos para comprobaciones con estado, registros de despliegue y el registro de reparación. Otra persona técnica debe poder repetirlo sin instrucciones orales.

Exige que el paquete registre lo que el equipo no pudo probar. La falta de acceso a un entorno de pago de prueba, una migración de producción desconocida o un secreto de firma no disponible cambia la confianza de la decisión. Un límite sin probar no cuenta como fallo, pero tampoco puede pasar en silencio. Asigna un dueño y una fecha de resolución a cada hueco y decide si bloquea la aprobación o aumenta la reserva para investigación.

Las personas propietarias sin conocimientos técnicos deben revisar los nombres de las reglas y los resultados de negocio, mientras el equipo técnico revisa el aislamiento, los datos de prueba y los artefactos. Esta división no pide a una persona fundadora que juzgue SQL ni a una desarrolladora que invente políticas comerciales. Expone pronto los desacuerdos. Si una cancelación debe conservar el acceso hasta el final del periodo, escribe esa política antes de que una prueba codifique otra respuesta.

FixMyMess usa diagnóstico del código y verificación experta junto con herramientas asistidas por IA para evaluar este tipo de aplicación heredada. Una auditoría gratuita del código puede ayudar a saber si los fallos requieren reparar lógica, reforzar seguridad, refactorizar, preparar el despliegue o marcar un límite de reconstrucción, pero la aprobación debe seguir basándose en el paquete de evidencias.

Pon precio a la incertidumbre de forma abierta. Una reparación de autorización acotada puede tener una prueba de aceptación clara. Un esquema de producción desconocido, la configuración ausente del proveedor o un modelo de propiedad inexistente necesitan una reserva de investigación o una decisión de reconstrucción aparte. Esconder la incertidumbre dentro de una estimación segura crea el peor proyecto de recuperación: el que sigue casi terminado mientras cada ruta reparada descubre otra fuente de verdad.

Las pruebas automatizadas se ganan su lugar en la decisión cuando permiten negarse. Si el conjunto de evidencias no puede detener la reparación tras efectos de ingresos duplicados, fugas entre clientes, reintentos que corrompen datos o un despliegue que nadie puede reproducir, es material de venta. Construye la puerta pequeña, conserva sus fallos y financia solo los límites que haga visibles.