Extension e2e Testing

[Cenell Harrell]

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]

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]

Thank you for the information. This is helpful!

ᐧ

[Cenell Harrell]

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]

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]

Cenell Harrell <cen...@vid.io>	visibility Mon, May 16, 3:01 PM (10 days ago)
to Simeon, Chromium

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?

ᐧ