Extension e2e Testing

192 views
Skip to first unread message

Cenell Harrell

unread,
Apr 6, 2022, 12:02:32 PMApr 6
to Chromium Extensions, Simeon Vincent
Hi Simeon,

We have a question regarding End to End testing for our extension. To cut down on manual testing overhead and improve the reliability of our browser extensions, we would like to introduce end-to-end testing for them.

Workflow

As usual with end-to-end testing, we would automate the user’s journey.

So:

  • Visiting YouTube
  • Testing user actions in logged out state
  • Logging in with a special CI Google account
  • Testing user actions in a logged-in state.
Past problems
  • Captchas on login
  • Blocking of our CI machines
Possible solutions
  • Whitelisting a set of CI IPs
  • Whitelisting our CI Google account

We obviously don't know whether such whitelists even exist but the point is that regardless of the precise mechanism, both captchas, as well as blocking of our CI machines, would need to be prevented for end-to-end tests to be possible. Will this be possible for us to implement?


Best,

Cenell D. 

Simeon Vincent

unread,
Apr 8, 2022, 5:26:02 PMApr 8
to Cenell Harrell, Chromium Extensions
Cenell, if I'm reading you correctly it sounds like you're asking Google to provide a special type of Google account explicitly for automated testing your extension on Google sites in continuous integration environments. Is that correct?

If so, I'm afraid I can't be of much assistance. To my knowledge Google does have any kind of special account that fits this use case. I suspect that Google probably won't provide this kind of account because it would be heavily abused to bot Google services. The closest thing I can think of is OAuth 2 testing using a standard Google account and using the oauth-playground to get a long lived refresh token as described here, but I don't think that's what you're after.

A potential workaround is to adjust your CI process. Rather than using a cloud CI system, you could have a single (or small number of) dedicated test devices. On these devices, you would use two separate Chrome profiles. One profile would be logged into a test Google account, the other would not be. You can use the Chrome CLI flag --user-data-dir=<path to directory> to specify which profile to load when launching Chrome.

Using dedicated test devices would allow you to avoid authentication/CAPTCHA issues at CI time as you would reuse existing sessions that have already successfully authenticated. 

Simeon - @dotproto
Chrome Extensions DevRel

Cenell Harrell

unread,
Apr 11, 2022, 11:02:39 AMApr 11
to Simeon Vincent, Chromium Extensions
Thank you for the information. This is helpful!

Cenell Harrell

unread,
Apr 28, 2022, 2:06:05 PMApr 28
to Simeon Vincent, Chromium Extensions
Thanks, Simeon again for providing us with a workaround solution. Looking more into your suggestions we came across an issue; The automated access solution you provided is prohibited by the terms of service. So we would need to get written permission from you or the team to actually implement your suggestion.

From https://www.youtube.com/t/terms:

"You are not allowed to [...] access the Service using any automated means (such as robots, botnets, or scrapers) except (a) in the case of public search engines, in accordance with YouTube’s robots.txt file; or (b) with YouTube’s prior written permission;"

Is it possible to receive written permission or should we look for other alternatives?

Cenell Harrell

unread,
May 16, 2022, 6:01:40 PMMay 16
to Simeon Vincent, Chromium Extensions
Hi Simeon and team,

Is there any update on this? 

Looking more into your suggestions we came across an issue; The automated access solution you provided is prohibited by the terms of service. So we would need to get written permission from you or the team to actually implement your suggestion.

From https://www.youtube.com/t/terms:

"You are not allowed to [...] access the Service using any automated means (such as robots, botnets, or scrapers) except (a) in the case of public search engines, in accordance with YouTube’s robots.txt file; or (b) with YouTube’s prior written permission;"

Is it possible to receive written permission or should we look for other alternatives?

Cenell Harrell

unread,
May 26, 2022, 5:40:04 PMMay 26
to Simeon Vincent, Chromium Extensions

Cenell Harrell cen...@vid.io

visibility
Mon, May 16, 3:01 PM (10 days ago)
to SimeonChromium
Hi Simeon and team,

Is there any update on this? 

Chrome team solution: A potential workaround is to adjust your CI process. Rather than using a cloud CI system, you could have a single (or small number of) dedicated test devices. On these devices, you would use two separate Chrome profiles. One profile would be logged into a test Google account, the other would not be. You can use the Chrome CLI flag --user-data-dir=<path to directory> to specify which profile to load when launching Chrome.

Using dedicated test devices would allow you to avoid authentication/CAPTCHA issues at CI time as you would reuse existing sessions that have already successfully authenticated. 


Looking more into your suggestions above we came across an issue; The automated access solution you provided is prohibited by the terms of service. So we would need to get written permission from you or the team to actually implement your suggestion.

From https://www.youtube.com/t/terms:

"You are not allowed to [...] access the Service using any automated means (such as robots, botnets, or scrapers) except (a) in the case of public search engines, in accordance with YouTube’s robots.txt file; or (b) with YouTube’s prior written permission;"

Is it possible to receive written permission or should we look for other alternatives?
Reply all
Reply to author
Forward
0 new messages