The data-test-id Debate: To Use or Not to Use?
For those of us who have a passion for code testing, automated testing plays a crucial role in web development. When talking about end-to-end or functional testing of web applications, one technique that often sparks a debate is the use of data-test-id attributes in HTML elements. This article delves into the pros and cons of using these attributes.
So What Are data-test-id Attributes?
data-test-id is a custom HTML attribute used to uniquely identify elements for automated testing. It serves as a stable hook for testing tools, allowing them to locate and interact easily with specific elements regardless of changes to styling, layout, structure, or any other non-functional aspects of the application.
So let's start by examining the arguments for and against using data-test-id attributes in web applications.
The Case For data-test-id
- Stability and Resilience:
Using data-test-id provides a stable selector, mitigating the risk of tests breaking or flakiness due to changes in CSS classes or DOM structure, which usually happens quite frequently on modern web applications being constantly developed. It is also especially vital in complex dynamic applications with frequent updates and state changes.
- Insulation from Style Changes:
Due to the fact that almost any new web application is being developed using some kind of a framework or a library (for example, tailwind), CSS classes are often subject to change for styling purposes in a more frequent way then it used to be changed in the past. Relying on them for testing often creates flaky tests.
- Improved Testing Efficiency:
Whatever you think on data-test-id usage, you can't deny its the most efficient method of building an automation testing framework from scratch. Due to the fact that it is a custom attribute, it is not used for any other purpose other than testing, which makes it a perfect candidate for testing and of course it makes our locators more quicker to find with less of an effort and time to figure out which selectors we should use.
- Improved Debugging:
During test failures, data-test-id attributes make it easier to pinpoint the problematic element, streamlining the debugging process which saves us time and effort.
- Dynamic Addition and Removal:
data-test-id attributes can be dynamically added or removed based on the environment using build tools, server-side rendering, or client-side JavaScript. This allows for their removal in production builds, addressing potential performance and security concerns (spoiler for some of the cons).
The Case Against data-test-id
- Potential Clutter and Performance Impact:
Leaving data-test-id attributes in production can increase the size of the DOM, potentially leading to slight performance degradation.
- Maintenance Overhead:
Maintaining unique and meaningful data-test-id values can become challenging in large applications, requiring consistent naming conventions and careful management.
- Security Concerns:
On some cases, if left in production, data-test-id attributes might inadvertently expose sensitive information about the application's structure or functionality for potential attackers.
- Scraping:
Simply put, these attributes can make web scraping much easier. While true, it is not the only way to scrape a web application.
- Discourage of User Facing Locators:
Using data-test-id encourages testing implementation details rather than user behavior. For example, if you look at Playwright's documentation, under best practices, they encourage using selectors that are visible to the user, such as text content, and other user-visible attributes. Although we need to be fair and say, they were mainly aiming at the usage of CSS selectors, and XPath which these days are considered as unreliable. You can find similar recommendations in the React Testing Library.
To conclude, let's go over of some of the best practices and considerations when using data-test-id attributes.
Naming Conventions: Establish clear and consistent naming conventions for data-test-id values (e.g., component-element-action).
Environment-Specific Handling: Use build tools or server-side rendering to remove data-test-id attributes in production.
Balanced Approach: Use data-test-id judiciously, complementing it with user-centric testing approaches that target user-visible attributes.
Avoid Over-Reliance: Do not rely solely on data-test-id. Test user flows and user visible information.
