UI test automation is at the top of the classic pyramid of tests 🔝 This means that these tests are slow to run, brittle and you shouldn’t have a lot of them. Even still they are incredibly important to have in your test suite and you better not ignore them, otherwise, you may find yourself executing way more manual tests than you need and wasting too much time unnecessarily.
In this article, I’m going to give you some tips on how to better write and maintain the automated tests for your user interface (UI).
Why even write UI test automation?
Of course before getting into the how we should be talking about the why. UI automation frameworks and test suites demand a lot of work and knowledge. Knowledge about how to choose a framework, programming and programming languages, creation of test data and debugging, and the challenges that are intrinsic to testing in general, like boundary value analysis and equivalence partitioning.
It also demands a lot of work. Creating new tests demands as much programming knowledge as we would expect from a developer, and maintaining requires familiarity with the company’s most recent requirements.
In the end, UI test automation is important. Even when taking into consideration all the challenges it brings, it gives us two things: speed, and confidence. Contrary to perhaps what common sense would tell, speed and confidence walk side by side in testing.
When we have a good UI automation test suite, we have fewer bugs in production, which means less developer time wasted on bug fixes, which results in more developer time being used to develop new features. As a result, we have more speed and more confidence in our features at the same time 💪
Getting the basics right: Selecting elements
One of the first things we need to have in mind is what selectors we are going to be using to get the elements in our project. There are many ways we can get an element. We could get them by CSS attributes like ID, class, or we could use XPath, a certain attribute, the text content, and choosing the wrong one for your case means more brittle tests that will have to be re-written.
Since resilience is a quality we wish to have in our tests, let’s have a look at each case in particular and see when we should or shouldn’t use them.
Let’s say we have a button element that we want to select and click, what should we use? XPath is not a good solution, it was widely used in the past but it is way too coupled to the page’s styling, which means it is not resilient against changes.
Selecting a certain class like “.btn” or “.btn large” is not a good solution either for the same reasons. Selecting by ID is not ideal but sometimes can’t be helped, the page could have dynamic IDs or they could be updated in the next version of the page.
In general, there are two good solutions, but one is better than the other to solve this problem: selecting an element by its text is better than the previous solutions. Texts are not coupled by the styling but the logic of the business itself, unless the business logic for the button has changed, it’s likely that the text within the button will not change as well.
An example of this is a page from an eCommerce website 🌐 The buttons with the text “Add to cart” and “Buy” are key aspects of the business itself and probably will not change frequently.
The best solution demands a little bit more work and something it cannot be solely done for the testers themselves, depending on the company. Changes in the text are infrequent but can happen. But if we had an exclusive attribute, used only for selecting that specific element, it would never change.
So, back to the button example- The tester would have to speak to the front-end developer responsible for that button and ask to have a specific testing attribute added, let’s say “t-button”. This attribute is immune to change. And now he can get the element selecting this attribute. Of course, it is not always possible but if you can do this you definitely should.
Even when you cannot find the best solution, it’s important to use the second-best solution possible. Don’t start using random solutions because the first one cannot be done.
Going even beyond the expected in UI automation
Sometimes even when explaining the importance of having an attribute, the developers won’t write them for you for many reasons, but it’s not because they don’t like you. Developers, just as testers, are busy, they have deadlines to meet, bug fixes to deploy, project managers over their shoulders, and sometimes your needs are not the top priority, but it is also the opportunity to distinguish yourself.
Writing your own attributes in the front end will demand that you learn some skills you are maybe not familiar with, and also you to speak to the front end team and get their approval. But if you manage to do that, you are going to be above the average automation engineer, and it will probably reflect on your next individual review, too. So take the initiative 😇
UI automation is hard, but doing the basics correctly is the key to being a good tester no matter the company you work for. The tech stack and tools may change, but selecting elements is a tool independent concept and can help you no matter what team, squad, or company you are working with.
In this article, you could see what is bad and what is good when selecting elements, but there are a lot more concepts to grasp and perfect when doing test automation. To constantly use the best practices in every new aspect is going to give you the best results in the long run, and certainly will make you great in UI test automation.
Hope you found this article helpful, and let me know if you have any questions in the comments 💢