Pruebas en verde, aplicación rota: el día de la integración

Hoy me ha tocado enfrentarme a lo que la suite no veía: la aplicación pasaba todas las pruebas y, al abrirla en el navegador, no funcionaba.

Tres fallos que ninguna prueba detectaba

Había tres. Una pantalla en blanco: para cualquier estado de sesión que no fuera «listo», la aplicación devolvía null, y un error de red se traducía en una página vacía sin ningún mensaje. El servidor de desarrollo de Vite toma el siguiente puerto libre cuando el anterior está ocupado, y como el servidor solo admitía un origen, el navegador bloqueaba la llamada a la API. Y el más silencioso: el formulario de acceso enviaba correo y contraseña con los nombres del contrato del proyecto, mientras que Better Auth esperaba email y password; la biblioteca recibía undefined en ambos campos y respondía con un error de validación.

La causa común de que ninguno se detectara es que las pruebas web simulaban la API. Comprobaban que se llamara a la ruta correcta, nunca la forma del cuerpo ni las cabeceras que llegaban al servidor. Una prueba que simula el límite exterior no puede detectar una discrepancia en ese mismo límite. Ahora la aplicación siempre pinta algo, con estado de carga y mensaje si la API no responde; el origen permitido es una lista que CORS y Better Auth reciben ya expandida; y la traducción de los nombres de campo vive en el único módulo que habla con la biblioteca, con pruebas del cuerpo exacto de las peticiones.

Roles disjuntos y un panel para cada uno

La primera versión de la vista por rol era una escalera: cada rol veía lo del anterior, y el reclutador tenía búsquedas de empleo y documentos. No es como funciona la gente: un reclutador no busca empleo, y el administrador gestiona la plataforma, no su búsqueda. Ahora cada rol ve solo el suyo, sin herencia; el reparto de secciones vive en un solo archivo que usan el menú y el selector; el superadministrador puede ver la aplicación como cualquiera de los tres roles; y cada rol entra por su propio panel con ruta propia para las búsquedas.

El administrador ya tiene una sección de configuración con todo lo que gobierna la plataforma de verdad: proveedor de IA, actor de Apify con su presupuesto por ejecución, remitente del correo y frecuencia de revisión de las búsquedas programadas. Y el reclutador ya puede hacer su trabajo: asignar un candidato a una de sus empresas, escribirle mensajes que llegan a su bandeja y ver los currículos generados, siempre con candidatos que le hayan autorizado expresamente.

Cuatro avisos en dos días

He tenido que avisar cuatro veces de que la aplicación no funcionaba en el navegador: una pantalla en blanco, un error de validación al iniciar sesión, un panel de administrador que no aparecía y un cambio de rol que dejaba la URL en una sección ajena. Ninguno era un fallo de lógica: todos eran de integración, y ninguna prueba los había detectado. El agente también cerró tickets declarando el trabajo hecho solo porque la suite pasaba, sin probar la aplicación en el navegador. La corrección del método: comprobar en el navegador antes de dar algo por terminado, y escribir pruebas que crucen el límite, no que lo rodeen.

Con el trabajo al día, la especificación describe lo que la aplicación hace hoy, hay veinte tickets cerrados y ocho abiertos, y una nota de traspaso con el estado y las trampas conocidas. Por la tarde, pantalla de acceso en dos columnas con la marca y el contraste comprobados, zona privada con cabecera y menú lateral como una aplicación de escritorio, tres cuentas de prueba para trabajar a mano, y el panel vestido de azul con un único tono para cabecera, lateral y pie.