Making E2E tests resilient and maintainable: my approach
In this post, I want to emphasize the importance of writing abstract and dynamic end-to-end (E2E) tests that only test what’s needed. Here’s how I managed to leave my E2E tests for months and find them all green.
These types of tests are more resilient to unscoped modifications and require less maintenance. I learned this firsthand when I had to leave my team, with whom I had developed a large number of E2E tests for our e-commerce website, to work with another team in my company with more pressing needs for quality assurance (QA). When I returned to my previous team months later, I was pleasantly surprised to find that all the tests were still green and testing exactly what was needed.
Here are some reasons why I think these tests were so successful:
The website was long-running
E2E tests are most cost-effective and valuable for applications that don’t change frequently, as constant refactoring can make them less effective. Since our e-commerce website didn’t change much, there were fewer ‘breaking’ changes that could have affected our E2E tests.
The tests were dynamic
Our website had a lot of products and category pages that constantly changed, so we had to take a dynamic approach to writing our tests. Instead of writing one test per page, we wrote tests that looked for specific elements on each page and ran the appropriate script based on those elements. For example, we used Playwright to write tests that looked for specific buttons or links on a page and ran the corresponding script. This approach allowed us to write tests that were more flexible and could adapt to changes in our website.
The tests only tested what was needed
We made sure to test only the most important elements on each page. For example, if we were testing a product page, we would test if the price (a regex) was visible, but we wouldn’t test if it was blue or red. This approach made our tests more efficient and focused.
When they failed, they really failed
To ensure that our tests were relevant and useful, we made sure that if they failed, there was a problem that needed investigation. We achieved this by making our tests specific and testing only what was needed.
In conclusion, tests are only useful if someone checks them, so don’t develop overly specific tests that can break on every change. Instead, focus on writing abstract and dynamic tests that only test what’s needed. Dynamic tests are more flexible and require less maintenance, which makes them a valuable asset for any QA team.
More on why we use Playwright? Check my other post here!
