Shadow DOM Elements and Using TestProject’s AI Recorder {Part 3}

So far {1st Part of Shadow DOM series  &  2nd Part of Shadow DOM series}, we are much familiar with Shadow DOM aspects as well as TestProject’s SDK flawless support for it. Now it’s high time to understand – How TestProject’s AI-powered Record/Playback feature leverages graceful handling of Shadow DOM elements? So without wasting a single moment, we should jump on TestProject’s AI-powered Self-Healing Test Recorder. I hope you would 💗 it!

Does TestProject’s record/playback feature directly record the Shadow DOM elements?

Record and playback features are a really useful tool for automated testing – especially for naive test engineers. The way they work is that the test engineers just click a record button, do some actions on AUT, and then click stop. When replaying the recording, the same actions should be performed.

When you do recording on TestProject, automation scripts are automatically generated and saved on the platform under your account. Later we can run the same scripts by playback feature. We can also make changes to the script to make the test run differently e.g. change selectors or test data. This allows the test engineer to update, maintain, and make improvements to the recorded scripts.

By default, TestProject’s record/playback feature records the web elements by using all legacy selectors {CSS, XPath, etc.}, moreover, it considers the Shadow DOM elements as plain DOM elements. In our application, we will record the Shadow DOM elements by taking two actions:

• Enter some text inside the element ‘enter-text-area’
• Click ‘btn-enter’ element

Let’s record and save the script on your TestProject account >

Let’s observe the recorded elements and rectify the problem >
Navigate to your account and open the respectively recorded script. Here we can clearly observe, it has no capability to record Shadow DOM elements inside the shadow-root i.e. ‘enter-text-area’ and ‘btn-enter’. Despite recording the Shadow DOM elements, it has recorded the general element “ID=todo-app’’ i.e. just outside the entry point of the shadow-root. Moreover, we can clearly see, it has used CSSSelector for the recording, which does not support Shadow DOM elements.

Let’s run the recorded scripts – if it FAILS or not? >
Of course, it would fail because – it will try to take action on the Shadow DOM elements that are actually recorded in the wrong way. We can clearly see the failed test report on our TestProject’s account:

Are we stuck or do we have an easy workaround to come out of this problem? So let’s solve this problem 😉👍

What tweaks are required in the recorded TestProject’s script, so that it can identify the Shadow DOM elements?
If we are good at our technology then we can tweak our stuff very easily – whenever automated recording fails then manual intervention comes into the picture. Let’s edit those recorded elements:

• Change TYPE from ‘Element Action’ to ‘Action’
• Select ACTION as ‘Execute JavaScript’ 
• Add CODE for ‘enter-text-area’ element i.e. your JS code to find Shadow DOM element

return document.querySelector('#todo-app').shadowRoot.querySelector('#adds-item')
.shadowRoot.querySelector('#enter-text-area').value='Demo Test'

• Add CODE for ‘btn-enter’ element i.e. your JS code to find Shadow DOM element

return document.querySelector('#todo-app').shadowRoot.querySelector('#adds-item')
.shadowRoot.querySelector('.btn-enter').click()

• Save all changes for both elements

Let’s run the updated scripts – if it PASSES or not? >
Of course, it would pass because – this time it will interact and take actions on the Shadow DOM elements. We can clearly see the passes test report on our TestProject’s account:

As a workaround >
📍We have seen that TestProject’s record/playback feature leverages options to edit the recorded script and moreover giving the option to add our own JavaScript. With the help of JS, we can interact easily with Shadow DOM elements. The best part of TestProject’s record/playback feature is its in-built handling of typecasting the WebDriver with JavascriptExecutor interface.

After my webinar on Selenium International Virtual conference 2020 – I came across one exciting query from many of the test engineers so let’s discuss it right here:

How to interact with Shadow DOM elements, if they reside inside the iFrame?
Truthfully, there is no change in the handling of Shadow DOM elements if they reside inside the iFrame or not. But before taking any action on iFrame’s Shadow DOM elements, we have to do context switching to iFrame and after taking our actions we can switch back our context to the main window.

📍An application that we have used above for the automation, can be found at – GitHub repo. This application is implemented by using Google’s Polymer library with NodeJS. So install those first before recording this application locally. 

Key Takeaways

• Clear thought – What tweaks are required in the recorded TestProject’s script, so that it can identify the Shadow DOM elements?
• Familiar with TestProject’s in-built typecasting of WebDriver with JavascriptExecutor
• Understood – How to interact with Shadow DOM elements, if they reside inside the iFrame?

Now we are completely handy with Shadow DOM trees with their elements and their graceful handling with TestProject’s Open SDK as well as Record/Playback feature. Happy testing guys and try to play with Shadow DOM and its elements.

💡 I would love to hear your thoughts in the comments below. Let’s start an open discussion on Shadow DOM  👍😊