Research guide
How to Test OAuth / Google Login in E2E Tests
Automating the real Google login page gets you blocked. This guide covers the reliable patterns: reusing a captured session, mocking the OAuth callback, seeding sessions, and the tiered strategy that keeps CI green.
Why automating the real Google login is wrong
Google actively detects automation: WebDriver flags, headless fingerprints, and unusual traffic trigger a “browser may not be secure” wall, CAPTCHAs, and lockouts on real accounts. The login UI also changes without notice, so selectors break.
You do not own Google’s DOM or its bot detection. Automating it makes the suite flaky at the exact moment you most need it stable.
Reuse a captured session
Log in to a test account once, save the session with storageState, and point the test config at it so every test starts authenticated. The suite never touches Google’s login page again.
If your stack stores OAuth tokens in localStorage or IndexedDB, a cookies-only snapshot is incomplete. Save with indexedDB enabled, or tests will mysteriously redirect back to login.
Mock the OAuth boundary
To test how your app handles the callback, intercept the flow at your app’s boundary: mock the callback and session endpoints with a known user, then assert your app lands in the authenticated state.
This is the fastest and least flaky pattern for pull-request CI, because it tests your handling of the token, not the provider’s UI.
Seed sessions with a test helper
Add a test-only endpoint that mints the same session the real callback mints for a known test user, and reuse the saved storageState across the suite.
The helper must mirror the real session shape: no fake logged-in flag that skips roles, claims, or permission checks, or you get a green suite that does not match production.
When you need a real flow
For the occasional real redirect test, use a separate sandbox OAuth app and test accounts, prefer the redirect flow over popups, keep credentials in CI secrets, and use one account per parallel worker.
Expect flakiness: consent pages vary by region and browser state. Run the real flow on a slower cadence, not on every commit.
The tiered strategy
Every pull request: seeded sessions and mocked callbacks. Nightly: a real sandbox OAuth flow against your test account. This keeps CI fast and green while still proving the full provider path periodically.
Pair this with the login-flow testing guide for the assertions that belong after authentication succeeds.
Key takeaways
- Keep Google’s login page out of CI: reuse a captured session or mock the callback.
- When you must go real, use a sandbox OAuth app, test accounts, and the redirect flow.
- Seed sessions that mirror production claims, or your green suite won’t match prod.