Des tests unitaires verts ne veulent pas dire que vous pouvez passer en production
Nous vendons de l'authentification, ce qui transforme notre question la plus angoissante en une question toute simple : quand un client branche son application sur nous et active tout, est-ce que ça marche vraiment, de bout en bout, sur le vrai système ? Pas "est-ce que les tests unitaires passent", mais : est-ce qu'un tout nouveau locataire s'inscrit, configure le SSO et SCIM et MFA et des claims personnalisés et le branding, dirige une vraie application vers lui, et connecte un vrai utilisateur avec les bons claims dans le jeton, via un vrai navigateur. Nous répondons à cette question de la seule manière en laquelle nous avons confiance : avec un test de bout en bout qui devient lui-même un client.
C'est une unique exécution Playwright, délibérément séquentielle et avec état, et elle parcourt toute la vie d'un locataire, de sa naissance à sa suppression. Un locataire s'inscrit, se fait configurer jusqu'aux dents, sert une vraie connexion à une vraie application grand public, est sauvegardé puis restauré, puis se supprime lui-même. Si un seul maillon de cette chaîne casse, l'exécution passe au rouge, et nous ne livrons pas.
Il configure tout, pas une tranche au chemin idéal
Le milieu du test est minutieux à dessein. Il ne se contente pas de se connecter et d'en rester là ; il parcourt chaque écran qu'un vrai intégrateur touche et l'exerce pour de vrai : un client OIDC personnalisé avec ses URI de redirection et ses réglages de jeton, un scope personnalisé qui émet des claims utilisateur, des rôles et une attribution de rôle, un utilisateur final avec un attribut personnalisé, un groupe avec une vraie composition et un mappage groupe-vers-rôle, des connexions d'entreprise SAML et OIDC, un jeton de provisioning SCIM, un domaine personnalisé, une application de provisioning sortant, un coéquipier invité puis rebasculé de rôle, la facturation via un vrai paiement, le journal d'audit avec des filtres et un export CSV, un environnement bac à sable, ainsi que les paramètres de sécurité, de webhook et d'e-mail (chacun basculé, puis ramené à un état sûr). Chacun de ces éléments est créé, vérifié et, là où c'est pertinent, supprimé, dans la même exécution.
L'objectif n'est pas de cocher des cases. Un client n'utilise jamais une fonctionnalité de façon isolée ; il utilise une combinaison, et c'est dans les combinaisons que les choses cassent en silence. Un claim personnalisé ne compte que s'il apparaît dans le jeton émis. Un mappage groupe-vers-rôle ne compte que si le rôle atterrit au moment exact où le jeton est forgé. La seule façon de le savoir, c'est de tout construire et d'aller ensuite s'en servir.
La danse des identifiants
Voici la partie qui rend un test de bout en bout d'un produit d'authentification véritablement délicat : les identifiants n'existent pas au démarrage du test. On ne peut pas coder en dur un secret client ou un jeton SCIM, parce que tout l'enjeu est que le locataire les forge, frais, pendant l'exécution.
Le test fait donc exactement ce que fait un vrai intégrateur, en plus rapide. Il crée le client OIDC dans le portail et relit l'identifiant client et le secret. Il forge un identifiant Portal API en un clic et le capture. Il génère un jeton SCIM. Puis il injecte chacun de ces secrets fraîchement forgés dans l'exemple d'application grand public qui attend, réécrit la configuration de cette application avec les nouvelles valeurs, la déploie, et seulement alors il pilote la véritable connexion. Des identifiants nés à une étape sont injectés à l'étape suivante dans l'application testée, et le navigateur effectue une vraie redirection OIDC contre eux. L'intégration est une cible mouvante que le test ne cesse de réajuster sur elle-même à mesure qu'elle prend forme.
Cette application grand public est un vrai déploiement, pas un mock. Quand le test vérifie une connexion, une vraie application a réellement redirigé vers l'émetteur du locataire, a réellement récupéré un code, l'a réellement échangé, et le test décode le jeton obtenu pour confirmer que le claim personnalisé et le rôle mappé y figurent bel et bien. Ensuite il pousse les bords les plus difficiles : une page de connexion à la marque personnalisée derrière son interrupteur d'activation, et un webhook imposé qui doit bloquer une connexion que la politique refuse. Un test vert sur ce dernier point signifie que le chemin de refus fonctionne, et c'est le résultat dont on veut le plus être certain.
Multifacteur, pour de vrai
Une connexion par mot de passe ne prouve pas grand-chose à elle seule. L'exécution enregistre puis utilise un authentificateur TOTP et un identifiant WebAuthn via un authentificateur virtuel, de sorte que le second facteur est exercé comme celui d'un vrai utilisateur, pas remplacé par un bouchon.
La moitié que tout le monde saute : le récupérer
La plupart des tests de bout en bout s'arrêtent à "ça marche". Le nôtre continue jusque dans les parties auxquelles on ne pense qu'à 2 h du matin. Il prend une sauvegarde, supprime les données du locataire sous ses propres pieds, restaure à partir de cette sauvegarde, et vérifie que la configuration et les utilisateurs sont revenus intacts. Puis il exécute une suppression en libre-service propre de tout le locataire. Une exécution ne laisse rien derrière elle, et c'est aussi ainsi que nous savons que le déprovisionnement déprovisionne réellement.
Pourquoi c'est le test en lequel nous avons confiance
Un mur de tests unitaires verts vous dit que vos fonctions sont correctes. Celui-ci vous dit qu'un client peut entrer, construire l'intégration qu'il veut vraiment, avec les fonctionnalités de sécurité dont il a vraiment besoin, et que nous pouvons perdre ses données puis les lui rendre. C'est ça, la différence entre "le code est correct" et "nous pouvons passer en production".
Chaque fonctionnalité que cette exécution exerce (SSO et SAML, SCIM, MFA, claims et scopes personnalisés, branding, webhooks imposés, export d'audit) est dans le produit à tous les paliers, pas verrouillée derrière une montée en gamme entreprise. Voyez ce qui est inclus.