Test your DOM Markup with Data Attributes

Cole Turner
Cole Turner
2 min read
Cole Turner
Test your DOM Markup with Data Attributes
Blog
 
LIKE
 
LOVE
 
WOW
 
LOL

It’s no secret that as developers we forget to make tests a first class citizen of our applications. We don’t write enough unit tests and let tests become “old tests.” For this myself I’m guilty.

A little while ago while scrolling through my Twitter timeline, I came across a neat pattern that deserves more recognition. Test with data attributes.

Here’s your current test:

// <span class="email">Welcome!</span>
// <input class="email" type="email" value="hello@world.com" />
// <input id="the-password" type="password" value="hunter12" />

expect($('.greeting').text()).toBe('Welcome!'));
expect($('input[type="email"]').val()).toBe('hello@world'));
expect($('#the-password').val()).toBe('hunter12'));

And here’s the problem. When you update your design or change the markup, your tests will most likely break. Element IDs, CSS selectors, and attributes are volatile to tests. How do we solve this problem and reduce technical debt?

Use data attributes to designate testing selectors 👏
// <span data-test="greeting" class="email">Welcome!</span>
// <input data-test="email" class="email" type="email" value="hello@world.com" />
// <input data-test="password" id="the-password" type="password" value="hunter12" />

expect($('[data-test="greeting"]').text()).toBe('Welcome!'));
expect($('[data-test="email"]').val()).toBe('hello@world'));
expect($('[data-test="password"]').val()).toBe('hunter12'));

This simple change reduces the amount of times you have to update your tests when the UI changes. By using data attributes, we deliver the following:

  1. More reliable tests with zero impact because we know which UI is coupled to tests before they break.
  2. Reusable structures for selecting which elements to test.
  3. Avoiding loss of time spent debugging and updating tests.

This is important because it allows us to update our user interface, or change styles, while minimizing the impact that will have on our tests. This means that we will spend less time updating tests, and more time focusing on the next task at hand.

If I’ve just sold you on this pattern, then I’ve done my job. Having seen this issue come up time after time I recalled this awesome pattern. Feel free to share any other patterns or tips for building reliable tests without technical debt.

Cover image by Johannes Plenio.

 
LIKE
 
LOVE
 
WOW
 
LOL

More Stories

Why I Don't Like Take-Home Challenges

4 min read

If you want to work in tech, there's a chance you will encounter a take-home challenge at some point in your career. A take-home challenge is a project that you will build in your free time. In this post, I explain why I don't like take-home challenges.

Standing Out LOUDER in the Technical Interview

5 min read

If you want to stand out in the technical interview, you need to demonstrate not only your technical skills but also your communication and collaboration skills. You need to think LOUDER.

See more posts

Read it before anyone else. Subscribe to my newsletter for early access to the latest news in software engineering, web development, and more.