Las pruebas unitarias en verde no significan que puedas salir a producción
Vendemos autenticación, y eso convierte nuestra pregunta más aterradora en una bien sencilla: cuando un cliente conecta su aplicación con nosotros y lo enciende todo, ¿funciona de verdad, de principio a fin, sobre el sistema real? No "¿pasan las pruebas unitarias?", sino: ¿un inquilino recién creado se registra, configura SSO y SCIM y MFA y claims personalizados y branding, apunta una aplicación real hacia él e inicia sesión un usuario real con los claims correctos en el token, a través de un navegador real? Respondemos a eso de la única manera en la que confiamos: con una prueba de extremo a extremo que se convierte en cliente.
Es una única ejecución de Playwright, deliberadamente secuencial y con estado, y recorre toda la vida de un inquilino, desde su nacimiento hasta su eliminación. Un inquilino se registra, se configura hasta los dientes, sirve un inicio de sesión real a una app de consumo real, se respalda y se restaura, y luego se elimina a sí mismo. Si se rompe un solo eslabón de esa cadena, la ejecución se pone en rojo, y no publicamos.
Lo configura todo, no una porción del camino feliz
La parte central de la prueba es minuciosa a propósito. No inicia sesión y se da por satisfecha; recorre cada pantalla que toca un implementador real y la ejercita de verdad: un cliente OIDC personalizado con sus URI de redirección y su configuración de token, un scope personalizado que emite claims de usuario, roles y una asignación de rol, un usuario final con un atributo personalizado, un grupo con membresía real y un mapeo de grupo a rol, conexiones empresariales SAML y OIDC, un token de aprovisionamiento SCIM, un dominio personalizado, una app de aprovisionamiento saliente, un compañero de equipo invitado y reasignado de rol, la facturación mediante un pago real, el registro de auditoría con filtros y una exportación CSV, un entorno de pruebas, y los ajustes de seguridad, de webhook y de correo electrónico (cada uno conmutado y luego devuelto a un estado seguro). Cada uno de ellos se crea, se verifica y, donde tiene sentido, se elimina, en la misma ejecución.
El objetivo no es marcar casillas. Un cliente nunca usa una función de forma aislada; usa una combinación, y es en las combinaciones donde las cosas se rompen en silencio. Un claim personalizado solo importa si aparece en el token emitido. Un mapeo de grupo a rol solo importa si el rol aterriza en el momento exacto en que se acuña el token. La única forma de saberlo es construirlo todo y luego ir a usarlo.
El baile de las credenciales
Aquí está la parte que hace que una prueba de extremo a extremo de un producto de autenticación sea genuinamente incómoda: las credenciales no existen cuando arranca la prueba. No puedes codificar a fuego un secreto de cliente ni un token SCIM, porque el sentido entero es que el inquilino los acuñe, recién hechos, durante la ejecución.
Así que la prueba hace exactamente lo que hace un implementador real, solo que más rápido. Crea el cliente OIDC en el portal y vuelve a leer el id de cliente y el secreto. Acuña una credencial de Portal API con un clic y la captura. Genera un token SCIM. Luego inyecta cada uno de esos secretos recién acuñados en la aplicación de consumo de muestra que está a la espera, reescribe la configuración de esa app con los nuevos valores, la despliega, y solo entonces conduce el inicio de sesión de verdad. Credenciales nacidas en un paso se inyectan en el siguiente en la app bajo prueba, y el navegador completa una redirección OIDC real contra ellas. La integración es un blanco móvil al que la prueba se sigue reapuntando a sí misma a medida que toma forma.
Esa app de consumo es un despliegue real, no un mock. Cuando la prueba verifica un inicio de sesión, una aplicación real de verdad redirigió al emisor del inquilino, de verdad recibió un código de vuelta, de verdad lo intercambió, y la prueba decodifica el token resultante para confirmar que el claim personalizado y el rol mapeado están genuinamente dentro. Luego conduce los bordes más difíciles: una página de inicio de sesión con marca personalizada detrás de su interruptor de activación, y un webhook obligatorio que tiene que bloquear un inicio de sesión que la política deniega. Una prueba en verde en este último punto significa que la ruta de denegación funciona, que es el resultado del que más quieres estar seguro.
Múltiple factor, de verdad
Un inicio de sesión con contraseña prueba poco por sí solo. La ejecución registra y luego utiliza un autenticador TOTP y una credencial WebAuthn a través de un autenticador virtual, de modo que el segundo factor se ejercita como el de un usuario real, no reemplazado por un stub.
La mitad que todos se saltan: recuperarlo
La mayoría de las pruebas de extremo a extremo se detienen en "funciona". La nuestra sigue adelante hacia las partes en las que solo piensas a las 2 de la madrugada. Toma una copia de seguridad, borra los datos del inquilino bajo sus propios pies, restaura a partir de esa copia, y verifica que la configuración y los usuarios volvieron intactos. Luego ejecuta una eliminación limpia y de autoservicio de todo el inquilino. Una ejecución no deja nada atrás, que es también como sabemos que el desaprovisionamiento de verdad desaprovisiona.
Por qué esta es la prueba en la que confiamos
Un muro de pruebas unitarias en verde te dice que tus funciones son correctas. Esta te dice que un cliente puede entrar, construir la integración que de verdad quiere, con las funciones de seguridad que de verdad necesita, y que nosotros podemos perder sus datos y devolvérselos. Esa es la diferencia entre "el código es correcto" y "podemos salir a producción".
Cada función que esta ejecución ejercita (SSO y SAML, SCIM, MFA, claims y scopes personalizados, branding, webhooks obligatorios, exportación de auditoría) está en el producto en todos los niveles, no encerrada detrás de una venta adicional empresarial. Mira qué se incluye.