Meaningful Error Messages for iOS UI Tests
Debugging is an essential part of any development. The building is the first step of debugging and it can often be easier to make changes iteratively and build your code until each error resolves rather than reading your code and trying to understand where the problem is.
Methods like TDD suggest similar ways while developing new features. Instead of building, you should write tests first and then implement code changes until your code passes the test you already wrote.
Unfortunately, these are not sustainable ways for UI tests since they took a lot of time to run. It can be heartbreaking to see a meaningless error message after waiting minutes to check why the method we just added can’t click.
Not only when writing new tests, but also we need to check all reports and error messages after each test run at CI. When we see an error, it is critical to figure out what caused it. That’s why we need to create smart error messages so anyone who sees the message can quickly find where the problem is.
In my previous article, I tried to explain how we use expectations and check methods to be sure all elements are in the correct state before interacting with them. Here:
Our waitForElements method can check all elements’ existence and state in a second when everything is ok. But what happens when there are some elements missing?
We will end up getting an error message like this one. At first glance, we can say that 3 elements are not found but what we can’t say is,
- Were the identifiers of the elements set without any problems?
- Are we searching for elements with the correct type?
To investigate these problems,
- We can check our Views if there are any missing implementations to set identifiers.
- Check our page object codes to be sure about elements’ types.
- If we still can’t find the issue we should set debug points and run them which we don’t like to.
How do we improve the meanings of our error messages?
The previous error message shows us which elements are couldn’t be found and the types we search them. We can get the view hierarchy with the command below when our tests are just about to fail.
With the information, we scraped from these 2 strings, we’ve created smarter error messages that look like this. :
- It directly tells you which elements are not found.
- You can see a list of elements available on the page to compare without any extra debugging.
- It can also check if the element type is wrong and suggest you the correct type.
Thanks, Aytuğ for magical string operations that allow us to reach this result. You can see the implementation here if you like.
Conclusion
Return of investment for iOS UI testing can improve a lot if your team takes the right steps. We keep trying to find new ways. Thank you for reading and feel free to contact me if you have any questions.
