Testing Guides for Auth and Identity
Short answer
Firebase, OAuth, MFA, CAPTCHA, RBAC, and session testing—enterprise-grade auth E2E patterns. Each guide includes complexity maps, fixture patterns, probe-first Assert, and page-scoped FAQs—wired to TestChimp QA workflow where it helps maintenance and requirement coverage.
Guides in this section
| Guide | What you'll learn |
|---|---|
| Firebase Authentication Flows | Test Firebase Auth in E2E with the Auth emulator, custom tokens, email verification, and CI-safe per-run users—without shared staging accounts |
| Auth0 and Okta SSO in E2E | SSO UI flows are slow and flake in CI—use test tenant APIs to obtain tokens when the test is not about the IdP login page itself |
| Google, GitHub, and Social OAuth | OAuth popups break in headless CI; account linking creates duplicate-user edge cases |
| Magic Links and Passwordless Login | Magic links require real email capture; link expiry and single-use tokens need explicit negative tests |
| MFA and 2FA Flows | TOTP clock skew and one-time backup codes break naive replay tests |
| CAPTCHA-Enabled Flows Without Flakiness | CAPTCHA blocks automation unless you use vendor test keys or environment bypass—never rely on solving services for CI |
| Role-Based Access Control Matrices | RBAC requires combinatorial scenarios—UI hiding alone does not prove enforcement |
| Session Expiry, Refresh Tokens, and Idle Logout | Session bugs either log users out unexpectedly or keep them in too long |
| Clerk Authentication in Playwright | Clerk E2E—programmatic sign-in, org switching, session tokens, and per-run users without brittle hosted UI clicks in every spec |
| Passkeys and WebAuthn in Playwright | Passkey E2E—virtual authenticators, registration vs login, and fallback paths when WebAuthn is unavailable in CI |
How TestChimp applies to these guides
These guides are scenario playbooks—Arrange/Act/Assert patterns, fixture discipline, probe Assert—not product feature lists. When you wire them into your repo, TestChimp adds:
| Layer | What it does |
|---|---|
| Test planning as code | Markdown scenarios in Git consolidate business rules agents read on every PR (test planning) |
| SmartTests + AI steps | Playwright you own; ai.act / ai.verify for volatile UI without abandoning probes (SmartTests) |
| Requirement traceability | // @Scenario: links connect specs to plan rows—critical in complex products with many dimension combos (traceability) |
| Per-PR QA workflow | /testchimp test in Claude or Cursor with the TestChimp skill—not a web recorder (QA on Autopilot) |
| ExploreChimp | Non-functional bug capture on SmartTest paths—latency, UX confusion, accessibility gaps most suites miss (explorations) |
| Post-deploy evolve | /testchimp evolve closes plan and production gaps; TrueCoverage is one signal among explore findings and requirement holes |
Why record-replay and no-code tools fall short
Browser recorders and web-based no-code suites optimize click capture. They struggle with per-run seed data, probe Assert on authoritative state, requirement matrices in Git, and non-functional regressions on real user paths. TestChimp contrasts that approach: orchestrated QA where Claude (upskilled with the TestChimp skill) maintains SmartTests against markdown plans—see record-replay vs TestChimp.
Other guide sections
- Business flows · Auth · AI UX
- Integrations · UI patterns
- Industry verticals · Built with
- Testing guides hub
Frequently asked questions
Firebase vs Clerk vs Auth0—which guide?
Firebase for Google stack; Clerk for modern SaaS auth components; Auth0/Okta for enterprise SSO—all need per-run users, not shared staging accounts.
How do I test MFA without SMS flake?
TOTP seeds, test-only bypass routes, or emulator fixtures—see MFA and SMS integration guides.
Should auth tests use UI login every time?
UI login for auth UX specs; storageState or token Arrange for tests about downstream features—see shared auth state gotcha.