13 mayo 2026 · Corrida TestSprite 86 TCs · eco.lpdi.co
De los 28 tests no exitosos (14 FAIL + 14 BLOCKED), ninguno representa un bug real del producto. Los 14 FAILs son tests mal escritos que no entienden los patrones de LPDI (validación custom Svelte, checkboxes legales, hover menus). Los 14 BLOCKEDs son limitaciones de TestSprite (no puede subir archivos, cambiar viewport, ni medir performance). La única acción de desarrollo real es agregar "Ecosistema" como link explícito en el sidebar (ya en progreso como LAP-316).
TestSprite intentó enviar formularios con campos vacíos o emails inválidos y esperaba ver errores HTML5 nativos (required, type="email"). No los encontró.
LPDI usa validación custom con Svelte (variables reactivas + botón disabled), NO atributos HTML5 nativos. El sistema SÍ valida correctamente — el test buscaba la validación en el lugar equivocado.
CERO
La validación funciona perfectamente. Usuarios ven mensajes de error y botón deshabilitado cuando faltan campos.
Opcion A (recomendada): Reescribir estos 4 tests para que busquen el patrón Svelte (botón disabled + mensaje de error custom). Sin tocar codigo del producto. Tallaje S.
Opcion B: Marcarlos como "covered by Playwright" (ya validados con Playwright en rondas previas) y no reescribir. Cero esfuerzo.
TestSprite intentó acceder al módulo Networking y encontró un badge "Próximamente" sin contenido funcional.
El módulo Networking no está desarrollado aún — es una fase futura. El badge "Próximamente" es intencional y correcto.
CERO
Es funcionalidad planificada. El usuario ve claramente que no está disponible todavía.
Opcion A (recomendada): Postergar este test hasta que el módulo Networking entre en desarrollo. Marcarlo como "deferred".
Opcion B: Reescribir el test para que VERIFIQUE que muestra "Próximamente" (convertirlo en test positivo del placeholder).
TestSprite buscó un link "Ecosistema" en la navegación lateral del dashboard y no lo encontró como item de menú.
El acceso a Ecosistema existe via el logo de LPDI (arriba del sidebar), pero no como ítem de navegación dentro de la lista del menú. El test esperaba un link explícito.
BAJO
Usuarios pueden llegar al Ecosistema por el logo, pero no es intuitivo. Mejora la UX tenerlo como link en el sidebar.
Opcion A (recomendada, ya aprobada): Agregar "Ecosistema" como item del sidebar debajo de "Inicio", mismo estilo tipográfico e ícono. Ya en progreso como LAP-316.
Opcion B: Dejarlo solo accesible vía logo. El test se reescribe para buscar el logo-link.
TestSprite intentó registrar una startup pero el form bloqueó el envío con mensajes: "Debes aceptar Términos y condiciones" y "Política de privacidad".
El test no marcó los 3 checkboxes obligatorios (Términos, Privacidad, Consentimiento CEO). El form de LPDI los requiere — el sistema funcionó correctamente al bloquear el envío.
CERO
La protección legal funciona. Usuarios reales ven los checkboxes y los marcan.
TestSprite intentó crear un ICG desde el dashboard y recibió errores: "País de origen requerido" y "Seleccione países de operación".
El test no incluyó instrucciones para llenar los campos obligatorios del formulario ICG. El sistema validó correctamente.
CERO
Los campos obligatorios protegen la integridad de datos. Funcionan como se diseñaron.
TestSprite envió datos incompletos al formulario de registro y el form los bloqueó correctamente.
Mismo patrón: instrucciones del test incompletas. El formulario funciona bien.
CERO
Opcion A (recomendada): Reescribir los 3 tests con instrucciones campo-por-campo que incluyan checkboxes legales, país de origen, países de operación, y todos los required fields. Tallaje S, sin tocar codigo.
Opcion B: Marcar como "covered by Playwright" (rondas 4-7 ya validaron estos flujos completos).
TestSprite buscó un botón "Eliminar" en la card del ICG y no lo encontró visible.
El botón Eliminar aparece al hacer hover sobre la card o dentro de un menú contextual. TestSprite no ejecutó la acción hover previa.
CERO
La funcionalidad de eliminación existe y opera. Usuarios descubren el botón naturalmente al interactuar con la card.
Opcion A: Reescribir el test para que haga hover antes de buscar el botón. Tallaje S.
Opcion B: Marcarlo como cubierto por Playwright (ronda 6 ya validó eliminación + restauración).
TestSprite intentó verificar que el sistema envía emails de confirmación post-registro y de recuperación de contraseña. No pudo completar el flujo.
Estos flujos requieren acceso a un buzón de email real para verificar que el correo llegó y hacer click en el link. TestSprite no tiene acceso a email. Además, el flujo branded LPDI con Resend está en desarrollo.
CERO
Estos tests cubren el flujo de email Resend (TC-R9-01..04) que se excluyó intencionalmente de esta corrida porque está en desarrollo.
Opcion unica: Postergar hasta que el flujo Resend branded LPDI esté code-complete. Los TC-R9-01..04 ya están diseñados para validar esto. No hay acción posible ahora.
TestSprite buscó el botón para abrir el modal de cambio de email y no lo encontró en el DOM.
El test no navegó a la ruta correcta dentro de la configuración de cuenta, o el botón tiene un selector diferente al que el test esperaba.
CERO
La funcionalidad existe. El test simplemente no encontró la ruta de navegación correcta.
Opcion A: Reescribir el test con la ruta exacta al modal de cambio de email. Tallaje S.
TestSprite intentó validar la respuesta del endpoint que lista las entidades que se perderían al borrar la cuenta. No pudo verificar el schema del response desde la UI.
Este es un endpoint server-side que requiere llamada POST directa, no interacción por UI. TestSprite solo puede interactuar con la interfaz gráfica.
CERO
El endpoint funciona — es una limitación de la herramienta de testing, no del producto.
Opcion A (recomendada): Mover a test backend (Vitest + supertest). Se valida la API directamente, no por UI.
Opcion B: Reescribir el test para que verifique la UI del modal de eliminación (que consume este endpoint internamente).
Ninguno de los 14 BLOCKED es un bug del producto. Son limitaciones técnicas de TestSprite (no puede subir archivos, cambiar tamaño de pantalla, medir tiempos de carga, ni modificar credenciales del usuario de prueba). Todos estos flujos ya fueron validados con Playwright en las rondas 4-7.
TestSprite no pudo interactuar con los inputs <input type="file"> porque corre en un sandbox headless sin acceso al sistema de archivos local.
Limitación inherente de TestSprite: el runner headless no puede simular la selección de archivos del explorador del sistema operativo. TC-R8-01 además requiere sembrar datos por API antes de poder probar eliminación.
CERO
Todos los uploads funcionan. Validados exitosamente con Playwright en rondas 5 y 7, donde sí se pueden inyectar archivos al input.
Opcion unica: Marcar como "covered by Playwright". No hay forma de testear uploads en TestSprite — es una limitación conocida de la herramienta.
TestSprite corre a resolución fija 1280x720 y no tiene API para cambiar viewport a 375px.
Limitación de la herramienta: no puede cambiar resolución durante la ejecución de tests.
CERO
Diseño responsive validado con Playwright a 375x812. El drawer mobile (LAP-315) está desplegado y funcional.
Opcion unica: Marcar como "covered by Playwright". Para mobile testing, Playwright es la herramienta correcta.
TestSprite no puede ejecutar la API performance.timing desde su sandbox para medir tiempos de carga.
La API de performance del navegador no es accesible desde el contexto de ejecución de TestSprite.
CERO
Medido con Playwright: Ecosistema carga en 1.04s (requerimiento: <3s) y Dashboard en 0.79s (requerimiento: <2s). Ambos pasan holgadamente.
Opcion unica: Marcar como "covered by Playwright". Performance excelente — muy por debajo de los umbrales requeridos.
TestSprite no ejecutó cambio de password/email porque hacerlo rompería los demás tests que usan las mismas credenciales.
El usuario de prueba qa-test@lpdi.co es compartido por toda la suite. Si se le cambian las credenciales, los tests siguientes fallan en cadena.
CERO
Las funcionalidades de cambio de password y email existen y funcionan. El bloqueo es por diseño de la suite de tests.
Opcion A (recomendada): Crear un usuario E2E secundario (e2e-destructive@lpdi.co) dedicado exclusivamente a tests destructivos. Tallaje S.
Opcion B: Ejecutar estos tests al final de la suite y restaurar credenciales con script post-test.
TestSprite no pudo verificar qué muestra el dashboard cuando un usuario no tiene startups ni ICGs registrados.
El usuario E2E qa-test@lpdi.co ya tiene entidades asociadas (creadas por tests anteriores). No se puede testear el estado vacío con este usuario.
BAJO
Si un usuario nuevo entra sin entidades, debería ver un mensaje guía (empty state). Vale validar que esa pantalla exista y sea clara.
Opcion A (recomendada): Crear usuario E2E secundario sin entidades para validar empty states. Se resuelve junto con TC-R4-11/12 arriba. Tallaje S.
Opcion B: Validar manualmente con un usuario nuevo fresco.
El test requiere verificar que el modal de eliminación de cuenta existe, pero explícitamente NO ejecutar la eliminación (porque borraría el usuario de prueba).
TestSprite interpretó que no debía interactuar con el modal por seguridad, y se bloqueó preventivamente.
CERO
El modal existe y funciona. Es solo una cuestión de cómo el test fue instruido.
Opcion A: Reescribir el test para que abra el modal, verifique su contenido (título, botón cancelar, advertencia), y lo cierre sin ejecutar. Tallaje S.
Opcion B: Usar el usuario destructivo secundario y sí ejecutar la eliminación completa.
Sin cambio de código del producto. Solo se mejoran las instrucciones de los tests para que entiendan: validación Svelte, checkboxes legales, hover en cards, rutas correctas a modales. Resultado: los 14 FAIL pasan a PASS en la próxima corrida.
Opciones: A) Reescribir todos (14 tests). B) Reescribir solo los críticos (F2, F3, F4 = 10) y marcar F1 como "covered by Playwright".
Desbloquea 4 de los 14 BLOCKED (cambio password, cambio email, empty state, eliminar cuenta). Sin este usuario, esos tests nunca se podrán correr.
Opciones: A) Crearlo ahora y reescribir los 4 tests. B) Postergar hasta que sea necesario testear esos flujos.
Los 6 de file upload + 2 de mobile + 2 de performance ya fueron validados exitosamente con Playwright. TestSprite simplemente no puede cubrirlos por limitaciones técnicas. Se documentan como cubiertos y no se reintentan.
Opciones: A) Aceptar Playwright como cobertura suficiente. B) Buscar herramienta alternativa (no recomendado — Playwright ya los cubre).
Este endpoint no se puede validar por UI. Se necesita un test Vitest que haga POST directo a la API y valide el schema de respuesta.
Opciones: A) Crear test backend con Vitest. B) Reescribir como test de UI que valide el modal de eliminación (que usa el endpoint internamente).
El módulo Networking no existe aún — no hay nada que testear.
Opciones: A) Postergar hasta que Networking entre en desarrollo. B) Reconvertir el test para validar que el badge "Próximamente" se muestra correctamente (test positivo del placeholder).