Actualización del producto KENSAI: las evidencias de las pruebas nocturnas sustituyen a las métricas tranquilizadoras

El 26 de abril comenzó con el tipo de fallo que los sistemas útiles deberían conservar en lugar de disimular: el conjunto nocturno de pruebas freemium no se completó correctamente. La buena noticia es que ahora el fallo es lo bastante preciso como para corregirlo.

Lo que demostró la ejecución nocturna

El registro de cron del 26 de abril documentó el conjunto completo de pruebas freemium de KENSAI desde el repositorio de la plataforma. El resultado no fue una compilación fallida sin más detalles. Fue un mapa concreto de fallos: pnpm test terminó con el código 1 después de 636 pruebas, de las cuales 310 fallaron, 243 se superaron y 83 se omitieron.

La clase de fallo dominante correspondía a pruebas respaldadas por la API que esperaban un servicio en 127.0.0.1:4000 cuando la API no estaba disponible, lo que provocó rechazos de conexión y aserciones con estado cero. No se trata de un misterio del producto. Es un defecto en la comprobación previa y la orquestación del servicio.

Lo que faltaba

También se registraron otros dos problemas en lugar de ocultarlos. El paquete raíz no definía pnpm test:e2e, por lo que el ejecutor no disponía de un punto de entrada e2e estable. El comando de cobertura falló inmediatamente porque faltaba @vitest/coverage-v8. Se inició una ejecución alternativa directa con Playwright, pero los numerosos fallos de autenticación y administración, junto con los tiempos de espera de validación de un minuto, generaron suficiente ruido como para detenerla en vez de interpretar erróneamente los resultados como una señal útil.

Por qué esto es una actualización del producto

Una ejecución de pruebas fallida no supone un avance por sí sola. Una ejecución fallida que incluye cifras, clases de errores dominantes, herramientas ausentes y la siguiente vía de reparación sí supone un avance. El sistema de calidad ahora distingue entre un fallo en el comportamiento de la aplicación y una infraestructura que nunca llegó a iniciarse.

Esto es importante para KENSAI porque las afirmaciones de seguridad dirigidas a los clientes dependen de una verdad operativa poco llamativa. Si la ruta freemium necesita la API, el ejecutor debe iniciarla o verificarla antes de que comiencen las pruebas. Si la cobertura es un control obligatorio, el proveedor debe estar instalado. Si e2e forma parte del proceso de lanzamiento, necesita un script real en lugar de una convención implícita.

Siguiente vía de reparación

La secuencia de reparación ya está clara: añadir o restaurar un script raíz test:e2e, instalar el proveedor de cobertura y hacer que el ejecutor freemium inicie y compruebe el estado de la API en el puerto 4000 antes de ejecutar las pruebas que dependen de ella. Cualquier otra cosa sería puro teatro.

Este es el estándar que KENSAI debe mantener: conservar la medición incómoda, identificar las condiciones previas incumplidas y convertir una ejecución fallida en una breve lista de correcciones.

Conclusión

El estándar útil es sencillo: las afirmaciones se hacen realidad cuando el requisito previo, el artefacto y la ruta están alineados. El trabajo de hoy mantiene visible ese estándar.