El punto de partida honesto
Si no sabes leer código, no puedes revisar el código, y deberías dejar de sentirte mal por ello. La alternativa no es revisar: es comprobar el comportamiento. Es lo que harán tus usuarios de todos modos, y detecta un tipo de problema que la lectura pasaría por alto.
Dónde suelen estar los bugs en el código de Lovable
Las apps generadas fallan en un orden predecible. Comprueba esto primero.
| Parece guardado, pero no lo está | Un formulario muestra un mensaje de éxito y, al recargar, el registro ya no está. Recarga siempre la página antes de creerte un guardado. |
| Estados vacíos y de error | El camino feliz se construyó y se demostró. Los casos de cero resultados y de petición fallida, a menudo no. Pruébalo sin datos y con una entrada deliberadamente incorrecta. |
| El segundo usuario | Todo funciona para la cuenta que construyó la app. Los permisos, la propiedad de los datos y la visibilidad son lo primero que se rompe para cualquier otra persona. Inicia sesión con una segunda cuenta antes de enseñársela a nadie. |
La comprobación que sigue funcionando
Comprobar a mano está bien para un proyecto de fin de semana y deja de escalar en cuanto sigues escribiendo prompts. Cada nueva instrucción puede deshacer en silencio algo que ayer funcionaba, y cada pasada manual se vuelve más corta que la anterior.
Lo que quieres es que las comprobaciones queden escritas y se ejecuten automáticamente, descritas en lenguaje natural en lugar de en código de test. La configuración pone esa capacidad en manos del agente, de modo que la comprobación ocurre a la vez que la construcción.
Todo esto también está disponible en el dashboard de TestSprite, que suele ser la mejor vía si la terminal no es donde trabajas. Los detalles del CLI están en el repositorio del CLI.
Tres comprobaciones que vale la pena tener desde el primer día
Regístrate y vuelve a iniciar sesión. Aquí se rompen más apps generadas que en ningún otro punto, y es lo primero que hace un usuario real.
Crea algo, recarga y confirma que sigue ahí. Esta única comprobación detecta el fallo más común y más vergonzoso.
Haz aquello para lo que existe tu app, desde una cuenta recién creada. Si eso funciona para un desconocido, tienes algo.
Cómo describir un bug para que la corrección acierte
Cuando algo falla, el instinto es decir "esto está roto". Eso le da muy poco al agente, y lo que recibirás de vuelta es un cambio que arregla algo adyacente.
Tres frases funcionan mucho mejor, y no necesitas vocabulario técnico para ninguna de ellas. Qué hiciste, en orden. Qué esperabas. Qué pasó en su lugar. "Completé el formulario e hice clic en guardar, esperaba ver el elemento nuevo en la lista, la lista estaba vacía hasta que recargué" es un reporte de bug genuinamente bueno, y apunta directo al defecto.
Esas mismas tres frases son también la comprobación que conservas. Escritas una sola vez, pueden volver a ejecutarse después de cada cambio futuro, y así es como evitas que el mismo problema regrese.
En qué orden comprobar las cosas
Hay una secuencia que encuentra problemas más rápido que andar haciendo clic sin rumbo, y lleva unos diez minutos.
Empieza con la sesión cerrada y regístrate como un usuario totalmente nuevo, porque ese es el camino que tú menos has recorrido. Después haz lo único para lo que existe tu app, de principio a fin, y recarga la página antes de creerte nada. Luego hazlo mal a propósito: deja en blanco un campo obligatorio, escribe texto donde va un número, sube algo absurdo. Y después elimina algo y confirma que de verdad desapareció en lugar de quedar oculto.
Cada una de esas cuatro lleva uno o dos minutos y cada una corresponde a un grupo de fallos donde las apps generadas se rompen. Hacerlas en ese orden importa, porque un registro roto vuelve imposible de probar todo lo que viene después, y es habitual que alguien pase una hora en una funcionalidad a la que nadie puede llegar.
Cuando llegue el momento de compartirla
Antes de que una app llegue a cualquier sitio real, haz que las comprobaciones se ejecuten automáticamente en cada cambio y no cuando te acuerdes. Dos formas de lograrlo:
Conecta el repositorio desde el dashboard y las ejecuciones arrancan desde el despliegue que ya generas, o bien añade un paso a tu propio flujo de trabajo.
Cómo TestSprite hace las comprobaciones por ti
Describes en lenguaje natural lo que debería cumplirse y TestSprite se encarga de los clics. Sin código de test, sin framework y sin terminal: crea un proyecto en el dashboard, apúntalo a tu app y describe cómo se ve una versión que funciona.
Los cuatro grupos de fallos de esta página son exactamente lo que cubre. Se registra como una cuenta nueva, crea algo y recarga para confirmar que persistió, envía algo inválido para comprobar que la app lo advierte, y ejecuta el mismo flujo como un segundo usuario para detectar las suposiciones sobre permisos que trae incorporadas tu propia sesión.
Lo que importa mientras sigues escribiendo prompts es que las comprobaciones se quedan. Cada cambio se verifica contra todo lo que funcionaba antes, y eso es lo que corta el ciclo en el que arreglar una cosa rompe otra en silencio.
¿Necesito saber programar para esto?
No. Las comprobaciones se describen en lenguaje natural y se ejecutan sobre la app a través de su interfaz, igual que la usaría una persona.
¿Por qué mi app funciona para mí y no para los demás?
Normalmente por permisos o por la propiedad de los datos. La cuenta que construyó la app tiene registros y accesos que una cuenta nueva no tiene. Probar como un segundo usuario lo revela de inmediato.
¿Debo probar antes o después de seguir escribiendo prompts?
Ambas cosas, y la segunda importa más. Una comprobación que ya existía antes de tu última instrucción es lo que te dice si esa instrucción rompió algo.
¿Y si la corrección no deja de romper otra cosa?
Esa es la señal para tener comprobaciones ejecutándose de forma continua en lugar de solo al final. Cada cambio se verifica contra todo lo que funcionaba antes.
¿Esto sirve solo para Lovable?
No. Los mismos fallos aparecen en cualquier cosa generada rápido, sin importar qué la haya producido. Quienes usan Lovable se topan con ellos antes porque publican antes.
No puedes revisar el código. Sí puedes comprobar el comportamiento.
La mayoría de los bugs en el código de Lovable son guardados que no persisten, estados vacíos que faltan y cosas que solo funcionan para la cuenta que las creó. Comprueba esos tres primero y después automatiza las comprobaciones antes de compartir la app.