Cómo testear una aplicación que no escribiste tú

Construir una aplicación ya no exige saber cómo se construyó. Los equipos publican software generado por herramientas de programación con IA, montado en plataformas low-code o entregado por un proveedor externo. El resultado funciona… hasta que en silencio deja de hacerlo.

El consejo habitual es escribir tests. Ese consejo da por supuesto que entiendes el código lo bastante bien como para testearlo, que es exactamente la suposición que ya no se sostiene.

Empieza por fuera

Cuando no puedes razonar sobre las tripas, testea lo que los usuarios hacen de verdad. No «¿devuelve esta función el valor correcto?», sino «¿puede alguien comprar un producto?».

Esto tiene una propiedad útil: no exige leer el código en absoluto. Necesitas saber qué se supone que hace el software, y casi seguro que lo sabes, porque tú lo pediste.

Escribe tus flujos más importantes en lenguaje corriente:

1. Un visitante nuevo puede crear una cuenta e iniciar sesión.
2. Un cliente que vuelve puede añadir un artículo a la cesta y completar la compra.
3. Un pago fallido muestra un error claro y no crea ningún pedido.
4. Un administrador puede encontrar un pedido y emitir una devolución.

Esa lista vale más que una suite grande de tests unitarios contra un código que nadie entiende.

Ordena los flujos por lo que cuesta romperlos

No todos los flujos merecen la misma atención. Ordénalos por el coste del fallo:

• Flujos de ingresos: todo lo que implique pago, suscripción o compra.
• Flujos de acceso: inicio de sesión, restablecimiento de contraseña, permisos. Que se rompa algo aquí deja fuera a todo el mundo a la vez.
• Flujos de integridad de datos: todo lo que escriba registros que no puedas reconstruir con facilidad.
• Todo lo demás.

Cubre los tres primeros como es debido antes de acercarte al cuarto.

Testea los caminos de fallo, no solo el camino feliz

El código generado tiende a manejar bien el caso previsto y mal el imprevisto, porque el prompt describía el caso previsto.

Así que testea qué pasa cuando se rechaza la tarjeta, cuando un campo obligatorio está vacío, cuando el mismo formulario se envía dos veces, cuando una sesión caduca a mitad de la compra. Ahí es donde el software escrito deprisa suele romperse.

Vuelve a ejecutarlos constantemente

El motivo por el que esto importa más en las aplicaciones generadas por IA y low-code es la velocidad del cambio. Cuando una funcionalidad se puede regenerar en una tarde, una suite de tests que se ejecuta una vez por publicación es casi inútil. Uses lo que uses, los tests tienen que ejecutarse con la frecuencia suficiente para detectar una regresión el mismo día que aparece.

Adónde lleva esto

El obstáculo práctico no suele ser saber qué testear: la lista de arriba no es difícil de escribir. Es que convertir esa lista en tests automatizados tradicionalmente exigía un ingeniero, y la razón misma de que la aplicación exista es que no había ingeniero disponible.

Esa brecha es la que Testmode está hecho para cerrar: los flujos de arriba, escritos en el mismo lenguaje corriente que acabas de usar para describirlos, ejecutados por usuarios sintéticos contra la aplicación real y sin necesidad de acceso al código fuente.