Katalon is a versatile automation testing tool for mobile and desktop websites. It has a lot of advantages and can be an interesting tool. But this blog post is not about that, it is about where it falls short, rather than where it succeeds.

Test Objects and changing base elements, not a match made in heaven.

Katalon makes test automation accessible with a convenient UI and several useful features like a test recording tool, solid logging and reporting and Test Objects. That last one is what we’re going to focus on here.

The concept of test objects is a good one. Keep all xpaths for relevant elements of your webpages in a single structured location. You can make folders for different webpages, add subfolders for complex elements of that webpage, and then a single test object for each element you want to observe or interact with.

However, despite all these advantages, there is one problem it doesn’t manage to solve. Obviously, when the website changes (as it tends to do during active development) you likely also need to change the xpaths of several test objects. This is easy because they’re all in the same place. Unfortunately, we often have a lot of elements that share the same base element, and if that base element changes, we have to change the xpath of every single test object that is contained within that base element. This potentially means that a lot of test objects need to be changed, and this is an area where Katalon’s UI works against itself, because while it’s convenient, it’s not exactly fast.

Finding more ways of managing xpaths

You either accept the tedious chore of regularly having to make the same change in a bunch of test objects, or you find a more convenient way of managing xpaths. One way to achieve this is to take advantage of the code behind Katalon test cases. Katalon test cases are coded in Groovy, and this means we can also simply manage our xpaths as a number of string constants in groovy files. We have the same advantages as test objects in terms of being able to logically structure and maintain our xpaths in one place. But because we’re using a programming language directly, we have the added advantages of using a code editor or IDE to maintain them (including powerful refactoring tools) and we can create xpaths composed of other xpaths. This means that, if a base path for multiple elements is changed, we only have to change it in a single location.

Of course, this change isn’t all positive. While you can also view these groovy files in Katalon, it isn’t ideal for it, and users who aren’t used to, or comfortable working with code might struggle to understand or maintain such a system.

Another factor to be mindful of is that Katalon won’t automatically acknowledge changes made to groovy files in external programs, so you will have to press F5 or click refresh every time you want to run a test after having made a change.

In short, taking advantage of the fact Katalon works with groovy, allows us to unlock both more powerful and more maintainable tests, but this comes at the cost of accessibility to less technically inclined testers.