The Hidden Case of the Shadow DOM
This article speaks to how shadow DOMs were used for the front-end web app development by my team, later bewildering the QA engineers who tested the application.
It also speaks to the journey wherein we set out together to solve the hidden case of these shadowed unique elements. We have discovered powerful tools to help us resolve this concern, and you’ll find a listing of these tools as well.
The web developers in my team had built a Medical web portal. When the app was rolled out to the QA engineers to test manually, all went fine. However, when they decided to automate the same test cases, they started facing issues. The test automation tool failed to locate certain elements for which actions were planned to be performed. This was a huge issue!
After the QA test automation team showed us the widgets that the automation locator failed to recognize, we noticed a common root cause of the issue. Well, all these widgets were associated with Shadow DOMs in the background and the rest is history!
Our team then went on to research automation tools that recognize Shadow DOMs automatically, and they were successful in resolving the issue. It was as simple as that!
Now, that was the short and sweet version of the story. As I’m sure you’d like to know more of the details, please read on.
What is the DOM, after all?
It is a hierarchical representation of the web object in JavaScript. For example, the HTML page is organized like a tree. DOM APIs are used to traverse and manipulate through the nodes of the tree.
See the image below:
What is the Shadow DOM?
So, why did the web developers in my team use the Shadow DOM, and why did it cause trouble for the test automation developers?
Shadow DOM is one of the trends in building modern web applications. We, from the web app team, used it specifically to enable encapsulation in the website as they are self-contained web components. That way, the widget code associated with the Shadow DOM will not interfere with the code used within the page, and vice versa.
Speaking of encapsulation, this shadow tree is isolated from the element’s children. It’s a part of the implementation which outside elements don’t need to know about. The Shadow DOM exists within the DOM, and cannot live without the DOM. Shadow DOM can be thought of as an isolated DOM element; it’s created on the fly as if it was part of the original doc.
The Background Hunt for the Shadow DOM
Why does a test automation tool that doesn’t support Shadow DOMs not spot them? Well, nodes from the host node are magically blended into a Shadow Root’s insertion points, yet logically, still remain in the host node. So, on rendering the page, they appear as part of the shadow tree and not the original host. How this rendering takes place is what confuses the test automation tool.
We used the Shadow DOM for the audio and video elements in the page. We also used it for the date picker for sections like the Patient appointment page. We also created our widgets which functioned as isolated Shadow DOM elements. None of these were located by the automation test tool. When you scroll over these types of elements on the page, they will not be automatically discovered by the test automation tool because they are shadow-ing behind DOMs.
See the image below -
Some examples are as below. Please look for the shadow-root among the inspected elements.
1. Video
For example, in the code, we had only mentioned the following line to get the video embedded into the HTML page. See the image below:
However, on inspecting the page, we see the following shadow root excerpt, which explains the real power behind the implementation of the video element. Encapsulation indeed!
If we right-click on the page and choose to “View Source,” we wouldn’t be able to see this detailed implementation as in the screenshot below. Only if you right-click on the page, and “Inspect” the web page, can you see the secret shadowed implementation behind the scenes as below. In short, all of this implementation is hidden from the user, unless inspected in detail using a developer tool. Isn’t that amazing? See the image below:
2. Date Picker
It’s the same case for the date picker that we had referred to in the HTML code. We had plainly mentioned the following. See the image below:
However, on inspecting it, we see the implementation in the background as follows, which gets the date picker functioning. See the image below:
How we resolved the hidden case of Shadow DOM
With the challenges faced by Legacy test recorders that could not detect these unique widgets, we started debugging the issue. Then, we (the web developers and the automation developers) looked for the tool that could help us through these challenges. The following lists a few tools that could help resolve these issues:
- TestProject’s OpenSDK supports Shadow DOM elements. TestProject recorder handles these situations for you automatically.
- Cypress tool also supports shadow DOM. The automation developer needs to use the command, i.e., “shadow(selector)” to traverse inside the shadow DOM of an element
- TestComplete also supports Shadow DOM trees. They can recognize elements present in the open shadow DOM trees. Accordingly, it can record and playback simulation of user actions such as clicks, inputs, etc. The Object Spy recognizes the web elements present in the shadow DOMs with ease.
- Selenium WebdriverIO supports Shadow DOM elements in a built-in way. Earlier, Selenium required you to write JavaScript code to interact with the ShadowDOM elements, which was cumbersome, but that has now been resolved with this support.
Wrapping Up
We, as web app developers, love to use the Shadow DOMs due to the clear advantages of encapsulation. We can embed these unique, powerful implementation elements with ease, and without disturbing the rest of the page.
Therefore, with all these advantages in mind, we encourage the QA test automation teams to update the QA test strategy to incorporate test automation tools that support recognizing and performing actions on Shadow Elements. With many new era tools to help you, choose the test automation tool wisely!
Tip: Share your reusable components between projects using Bit (Github).
Bit makes it simple to share, document, and reuse independent components between projects. Use it to maximize code reuse, keep a consistent design, collaborate as a team, speed delivery, and build apps that scale.
Bit supports Node, React Native, React, Vue, Angular, and more.
