How to better the automated test accuracy using data-test-id?
Who never passed the experience of receiving a notification from the pipe telling you that your automated tests have failed? And when it was checked, it was just some attribute changes of the mapped elements by some developer?
It is rare but always happens (LoL).
This is because many times the development team has not had time to communicate these changes, perhaps because an urgent implementation is needed or even a hotfix can change the element’s attribute and it is pushed into production.
What if we had a unique attribute for that??
Well, it exists! This attribute is called data-test-id, data-qa, or some other name like this.
Below, we have an example of an HTML common structure without the data-test-id attribute:
To add this attribute to this structure, the Verification Engineer should have access to the developer project, which may be aligned with the developers in case the company has a separate team between developers and testers, but in case it is a unique team, it will be easier.
It must be used in the same pattern as the developer team to add it, like below:
In this case, if you have some changes in the other attributes, all the data-test-id will not be changed, and, in case the data-test-id must be changed, the Verification Engineer may do that without additional concerns about the automated test failure.
Didn’t the data-test-id are the same source code as the developer team? How the developer can do these changes without affecting the test attributes?
Indeed, all the attributes are on the same source code, but the data-test-id is something like an untouchable thing. You may talk with your team in order for it to be clear, and let everybody know that this attribute may not be changed, and if it needs to, it will be done by a Verification Engineer.
Okay, we have seen how this attribute is shown in the DOM. But, how about the code?
Let’s see an example in C#, where we have a file with all the elements mapped and we use it in the classes. For this example, we’ll use a project with Page Objects pattern. In this project, we have a folder called UIMaps, where are allocated all files related to the UIMap:
And below, we have the way that it is mapped:
Then, inside the ApplicationLayer folder, we create a class (e.g.: AaPage.cs) that will be used for all the UIMaps which we have created above. Let’s use a simple method to click on the SiteMenu:
So, in this way, we have a clean code and we may interact with the mapped element inside the classes, and, when you need to use this method inside your TestClass (e.g.: AaTest.cs), you need just call it as AaPage.ClickSiteMenu();
Conclusion:
Using the data-test-id in your automation code will make your readability very easy. In case you need to change some already mapped elements, you will need to do it in only one place and then it will be replaced in your all automation code.
Your automation which is running on the pipeline will never fail by the changes are done on the elements in the DOM, because you have an exclusive test attribute.
Your code writing will make very clean also and you will have a TestClass much better readable and of easy maintenance.
And, last and not less important, this implementation is very easy and may be done during the development, some implementations for the day, and when you take a look at your code, everything will be done.
I hope I helped you with this article! Try it and let me know about your experience!
