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

Let me share our experience at Salesforce since we just transition a couple of thousand Selenium tests to work with shadow DOM, and our pages are quite dynamic and complex (thousands of multi-author/multi-version web components running within a page).

**TL;DR:** Very simple utilities were sufficient to have an "enterprise grade test codebase" migrated to use ShadowDOM and Web Components.

As @rniwa said above, any API that breaks encapsulation is a non-starter since it will defeat the whole purpose of web components and shadow DOM, but also, would be a foot-gun that would be fundamentally miss-used and ultimately would put us in the same position of _"reach-all-the-things"_ approach we are in today.

Precisely at our scale, we have suffered deeply from developers using complex global queries that rely on all sort of specific tree-structures and hierarchies. Terrible for scale and maintainability.

Using Shadow DOM is really helping us and our developers to "do the right thing" since they are now forced to follow a very explicit structure and a set of repeatable query patterns.

All we have done to enable this, is to provide a couple of helper methods to our WebDriver classes that facilitate navigation and traversal:

```java
/**
* Returns a test.util.webdriver.WebElement class that represents the elements shadowRoot property if it
* exists. Otherwise, returns the element parameter passed into this function.
* 
* Only call this function if you need to support scenarios where a shadowRoot property on an element may or may
* not be present. This is helpful for utility methods that run in different environments.
* 
* An important note here is if the shadowRoot property exists on an element then a ShadowRootWebElement class will
* be returned. This class attempts to represent what a shadowRoot would be on the client. Thus, not all standard
* WebElement APIs will be available. Clicking, for example, does not make sense to do on the shadowRoot on the
* client and thus will throw an error. See test.util.webdriver.ShadowRootWebElement for more details.
* 
* @param element the element to expand the shadowRoot property of
* @return a ShadowRootWebElement class representing the shadowRoot if it exists, otherwise the WebElement passed in
*/
WebElement expandShadowIfPresent(WebElement element);

/**
* Returns a test.util.webdriver.ShadowRootWebElement class that represents the elements shadowRoot property.
* 
* @param element the element to expand the shadowRoot property of
* @return a ShadowRootWebElement class representing the shadowRoot
*/
ShadowRootWebElement expandShadow(WebElement element);
``` 

We have also a series of what we call "pageObjects" that are fundamentally an abstraction of what a page looks like and how can I interact with different pieces of it, which again fits perfectly with the WC and Shadow DOM model.

As @caridy points out, it will be great to have these utilities as part of the Selenium protocol, but all of those should be just sugar on top of the current available APIs. Adding these in form of atoms in all drivers is pretty straight forward (we have already done some POCs).

We want to cover more ground and find more use-cases before doing a formal proposal, but we will be happy to work wit anybody interested in designing this APIs. I believe just a couple of helpers like the ones I described previously should be more than enough to cover any complex use case.

For the record, we have even fixed the IE11 driver to "fully" support ShadowDOM so we can actually build an enterprise level system working with WebComponents and ShadowDOM.


-- 
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-439782341