Re: [w3c/webcomponents] [WebDriver] Testability of web components (#771)

Just in case this discussion is still alive.

We're developing mid-sized (~250k sloc of client code) web app built from ground up using web components. All of the shadow roots are open. Depth of shadow roots is about 12-15 levels at max. All third-party components have opened shadow roots too.

For unit tests, and inter-component integration tests there is no need for any additional API since all internals are known and easily accessible. It's true even third-party components like vaadin-*, paper-*. For example to check that clicking on date input opens custom calendar popup, we can access shadowRoot directly in tests code, since they are being executed in browser using karma.

E2E on the other hand is tricky. My guess is that we invented the same wheel as @diervo did. To select elements in shadow DOM we collect selectors that include explicit information about shadow bounds (just like the `>>>` ) and then _for every query_ in WebDriver we inject JS script that traverses DOM and returns found element.

There is big chance I'm missing something since our E2E test base is extremely small due to considerable friction caused by the fact that explicit selectors are very fragile and require a lot of maintenance.
But testing looks possible w/o additional API from browsers. Perhaps wider adoption of WC will be possible when E2E-testing ecosystem gets mature in this regard. Solutions like Selenium IDE, Katalon, Cypress.io seem to work on shadow DOM support. I didn't tested it myself, but given [this](https://github.com/DevExpress/testcafe/issues/2432) I assume TestCafe already has some basic support.

IMHO the benefits of having native way of selecting elements behind shadow DOMs are following:
- eliminating race-conditions caused by need to inject helper content scripts
- more "honest" E2E testing that does not require modification of page under test, keeping it as close to production as possible
- not sure on this one, but I assume there will be performance improvement compared to the method I described above (injecting JS into page and traversing DOM).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/771#issuecomment-503863223