Grüne Unit-Tests bedeuten nicht, dass Sie live gehen können

Wir verkaufen Authentifizierung, und das macht unsere beängstigendste Frage zu einer ganz einfachen: Wenn ein Kunde seine Anwendung mit uns verbindet und alles einschaltet, funktioniert es dann wirklich, von Anfang bis Ende, am echten System? Nicht "laufen die Unit-Tests durch", sondern: Registriert sich ein brandneuer Mandant, konfiguriert SSO und SCIM und MFA und Custom Claims und Branding, richtet eine echte Anwendung darauf aus und meldet einen echten Nutzer mit den richtigen Claims im Token an, durch einen echten Browser. Diese Frage beantworten wir auf die einzige Weise, der wir vertrauen: mit einem Ende-zu-Ende-Test, der selbst zum Kunden wird.

Es ist ein einziger Playwright-Durchlauf, bewusst seriell und zustandsbehaftet, und er durchläuft das gesamte Leben eines Mandanten von der Geburt bis zur Löschung. Ein Mandant registriert sich, wird bis ins kleinste Detail konfiguriert, bedient ein echtes Login für eine echte Verbraucher-App, wird gesichert und wiederhergestellt und löscht sich dann selbst. Bricht ein einziges Glied in dieser Kette, wird der Durchlauf rot, und wir liefern nicht aus.

Er konfiguriert alles, nicht nur ein Happy-Path-Stück

Die Mitte des Tests ist mit Absicht gründlich. Er meldet sich nicht einfach an und ist fertig; er durchläuft jeden Bildschirm, den ein echter Umsetzer berührt, und nutzt ihn auch wirklich: einen Custom-OIDC-Client mit seinen Redirect-URIs und Token-Einstellungen, einen Custom-Scope, der Nutzer-Claims ausgibt, Rollen und eine Rollenzuweisung, einen Endnutzer mit einem benutzerdefinierten Attribut, eine Gruppe mit echter Mitgliedschaft und einer Gruppe-zu-Rolle-Zuordnung, SAML- und OIDC-Unternehmensverbindungen, ein SCIM-Provisioning-Token, eine eigene Domain, eine App für ausgehendes Provisioning, einen eingeladenen und neu zugewiesenen Teamkollegen, die Abrechnung über einen echten Checkout, das Audit-Log mit Filtern und einem CSV-Export, eine Sandbox-Umgebung sowie die Sicherheits-, Webhook- und E-Mail-Einstellungen (jede umgeschaltet und dann wieder in einen sicheren Zustand zurückgesetzt). Jedes Einzelne davon wird im selben Durchlauf angelegt, verifiziert und, wo es Sinn ergibt, gelöscht.

Es geht nicht darum, Kästchen abzuhaken. Ein Kunde nutzt nie ein Feature isoliert; er nutzt eine Kombination, und Kombinationen sind genau dort, wo Dinge leise kaputtgehen. Ein Custom Claim zählt nur, wenn er im ausgestellten Token auftaucht. Eine Gruppe-zu-Rolle-Zuordnung zählt nur, wenn die Rolle genau in dem Moment landet, in dem das Token geprägt wird. Sicher wissen kann man das nur, indem man das Ganze aufbaut und dann tatsächlich benutzt.

Der Anmeldedaten-Tanz

Hier kommt der Teil, der einen Ende-zu-Ende-Test eines Auth-Produkts wirklich heikel macht: Die Anmeldedaten existieren noch gar nicht, wenn der Test startet. Man kann kein Client-Secret und kein SCIM-Token fest verdrahten, denn der ganze Sinn besteht ja darin, dass der Mandant sie während des Durchlaufs frisch prägt.

Also tut der Test genau das, was ein echter Umsetzer tut, nur schneller. Er erstellt den OIDC-Client im Portal und liest Client-ID und Secret zurück. Er prägt mit einem Klick eine Portal-API-Berechtigung und fängt sie ab. Er generiert ein SCIM-Token. Dann speist er jedes dieser frisch geprägten Secrets in die bereitstehende Beispiel-Verbraucher-App ein, schreibt deren Konfiguration mit den neuen Werten um, rollt sie aus und steuert erst dann das eigentliche Login an. In einem Schritt geborene Anmeldedaten werden im nächsten in die zu testende App injiziert, und der Browser vollzieht damit eine echte OIDC-Weiterleitung. Die Integration ist ein bewegliches Ziel, auf das der Test sich immer wieder selbst neu ausrichtet, während sie Gestalt annimmt.

Diese Verbraucher-App ist ein echtes Deployment, kein Mock. Wenn der Test ein Login verifiziert, hat eine echte Anwendung wirklich zum Issuer des Mandanten weitergeleitet, wirklich einen Code zurückbekommen, ihn wirklich eingetauscht, und der Test dekodiert das resultierende Token, um zu bestätigen, dass der Custom Claim und die zugeordnete Rolle echt darin enthalten sind. Dann treibt er die schwierigeren Kanten an: eine individuell gebrandete Login-Seite hinter ihrem Aktivierungsschalter und einen erzwungenen Webhook, der ein Login, das die Policy ablehnt, blockieren muss. Ein grüner Test bei diesem letzten Punkt bedeutet, dass der Deny-Pfad funktioniert, und das ist das Ergebnis, dessen man sich am liebsten sicher sein möchte.

Mehrfaktor, und zwar echt

Ein Passwort-Login allein beweist wenig. Der Durchlauf registriert einen TOTP-Authenticator und ein WebAuthn-Credential über einen virtuellen Authenticator und nutzt sie anschließend, sodass der zweite Faktor so durchgespielt wird wie der eines echten Nutzers, nicht weggestubbt.

Die Hälfte, die alle überspringen: es wiederbekommen

Die meisten Ende-zu-Ende-Tests hören bei "es funktioniert" auf. Unserer macht genau dort weiter, wo die Teile liegen, an die man erst um 2 Uhr morgens denkt. Er erstellt ein Backup, löscht dem Mandanten die Daten unter den Füßen weg, stellt sie aus diesem Backup wieder her und verifiziert, dass Konfiguration und Nutzer unversehrt zurückgekommen sind. Dann führt er eine saubere Self-Service-Löschung des gesamten Mandanten durch. Ein Durchlauf hinterlässt nichts, und genau so wissen wir auch, dass Deprovisioning wirklich deprovisioniert.

Warum das der Test ist, dem wir vertrauen

Eine Wand grüner Unit-Tests sagt einem, dass die eigenen Funktionen korrekt sind. Dieser sagt einem, dass ein Kunde hereinspazieren, die Integration bauen kann, die er wirklich will, mit den Sicherheitsfeatures, die er wirklich braucht, und dass wir seine Daten verlieren und ihm wieder zurückgeben können. Das ist der Unterschied zwischen "der Code ist korrekt" und "wir können live gehen".

Jedes Feature, das dieser Durchlauf durchspielt (SSO und SAML, SCIM, MFA, Custom Claims und Scopes, Branding, erzwungene Webhooks, Audit-Export), steckt im Produkt in jedem Tarif, nicht hinter einem Enterprise-Upsell versteckt. Sehen Sie, was enthalten ist.