Guidance on UI integration testing of Chrome extension with Google Sign-In

[Vanya Sviridovich]

Hello,

We are developing a Chrome extension and need to run automated end-to-end integration tests against the real UI. Our tests involve signing in with Google and then interacting with various UI elements in the extension (clicking buttons, filling forms, navigating between views, etc.).

The problem is that these tests are frequently blocked by Google’s security systems during the login flow or even at later stages of clicking through the UI. As a result, it becomes nearly impossible to maintain reliable test coverage of our extension. Without automated UI tests, keeping the product stable and maintainable is very difficult.

We have already tried approaches such as:

• Running with Google profiles,

• Using Google Workspace accounts,

• Slowing down automation steps and using different environments.

Unfortunately, none of these approaches have solved the issue.

From what we found online, it seems that only API-level testing is officially supported, but in our case, we specifically need to test the UI flows of the extension to ensure correct behavior for our users.

Could you please advise:

1. Is there an officially supported way to run automated UI tests for Chrome extensions that require Google Sign-In?

2. Are there any recommended practices (e.g., special test accounts, sandbox environments, whitelisted configurations) to avoid triggering security blocks?

3. If UI automation is not possible, what best practice does Google recommend for testing extensions that depend heavily on signed-in user flows?

Any guidance, documentation, or workarounds would be greatly appreciated.

Thanks in advanced

[Deco]

So, generally, you will want to stick to established frameworks for automated UI tests. It is advised in order to avoid issues with CORS etc, that you use Playwright: https://playwright.dev/docs/chrome-extensions which should be able to do exactly as you're wanting without being blocked.

Thanks,

Deco

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/ff392138-1a28-4c24-87a0-a85540ab6742n%40chromium.org.

[Vanya Sviridovich]

Thanks for the suggestion!
Playwright can indeed handle Chrome extension automation, but our extension specifically works on Gmail and Google Calendar pages. When our Selenium/Playwright tests run in parallel, Google often blocks the test accounts due to suspected spam or unusual activity. Could you clarify how switching to Playwright would help avoid these security measures (CAPTCHA, account blocks, etc.) during Google Sign-In, or Gmail, Lalendar's UI interactions?

[Deco]

So, this is difficult, and depending on how your integration is setup, may not be feasible. At the heart, you need a persistent context for Playwright to access, that is someone who is already pre-authorised in order to bypass captcha flows, an option is to login once via a CI, then point Playwright to that profile. 

Regarding the calendar/Gmail, you will need to split these out from the hot path to work correctly, cover the Oauth exchange with unit/contract tests that call the token endpoints directly, which is a way to "simulate" the end to end user flow and get around this issue.

Fundamentally though, there's no way to directly emulate the session via automation without getting detected, you could perhaps have one running so infrequently that it won't be detected, say once per every few days to validate this flow, but there's no way you'll be able to do the direct user flow for the extension tests via this outside of some sort of emulated hook system. 

Hope that makes sense.

Thanks,

Deco

[Vanya Sviridovich]

Thanks for the reply. It seems I’m in the same spot—there’s no way to create a robust setup for 200+ extension UI tests to run daily without hitting Google’s security blocks. Maintaining such tests might cost more effort than building them in the first place