I used Katalon to record the steps for a web app. Katalon captured objects contains dynamically generated ids or classes or other attributes, so it’s failed to find the element the next time I replay it. I have to manually modify the object xpath using startwith and contains to ignore the dynamic part of the id/class/name of the element. This is time consuming if there are a lot dynamic elements.
Is there a way for Katalon to automatically ignore the dynamic part of the element when recording the steps?
No. There is no magic that automatically solve “dynamically genrated ids or classes” problem.
The only solution for you is to write manually a good XPath expression that can locate the element you want WITHOUT ids and classes. I mean, you need to study XPath technology from the basic.
If you are willing, see
Yes, I modified the xpath of the captured object which ignored the dynamic part and the test is running fine every time. But the thing is that I need to manully change the captured objects and there will be a lot of work for lots of pages.
You have created a lot of Test Objects and now you have to change all of them. Is that right?
I think that all you can do now is to do changing them manually one by one. No short-cut. Katalon Studio has no offering that change your Test Objects automagically.
I think that you are now aware that it is not a good idea to use the Recorder tool to generate a lot of Test Objects. You should have been cautious how much of maintenance efforts would be required for the bulk of generated codes. Once you have generated them, you need to maintaine them without tool’s assistance. It will be a lot of work, yes, as you wrote above. Sooner or later, you might give up doing the End-to-End testing at all due to the burden of code maintenance. Lesson learned.
I believe that well-experienced Katalon users refrain from relying on the Recorder tool. They would not casually generate a lot of Test Objects using the tool. Instead, they would make best efforts to minimize the number of Test Objects so that they can decrease the amount of efforts required to maintain their test suites in long term.
What part of the “dynamically created” IDs or class names can you use to write your xpath in a way that is easy to read/maintain?
I would stick to writing the xpath myself based on that…
For example, on a first name field on a page, whose HTML looked like:
<div class="row col-md-6">
<label for="field-First_Name_CF10106">First name: </label>
<input type=text id="field-First_Name_CF10106" required />
I would define the xpath to be:
contains() the descriptive part. Don’t do exact match.
Also, you can match any other attributes, such as
data-* attributes. Don’t be taken hostage by the convention of only matching against IDs or class names.
The Recorder tool of Katalon Studio never generates such XPath expression that uses a predicates like
[contains(xxx, xxx)] as @mwarren04011990 suggested. Therefore I find the tool is poor.
But sometimes I do use the Recorder tool. I use the tool to generate a Test Object which contains an XPath expression as a starting point. The generated expression is assured to be correct; it most probably works. Even if its XPath exression is poor, it is nice to have an instance that works. After generating the code as material, I would manually change it. I would modify the XPath (e.g, use predicates like
[contains(xxx, xxx)]) to make it more robust and maintenance-minimum; I would rename it if necessary; I would move it to some different folder location. Once a Test object becomes nice, then I would, if required, copy it to produce similar Test Object instances.
But I would never repeat using the Record tool to generate a lot of Test Object instances with poor XPath expressions.
There are hundreds and thousands of pages that need to do automated UI testing. It’s not possible to write every step and every test object for each page manually. Katalon recording tool will save a lot of time although need to manually change the dynamically created object. Some of the pages don’t have dynamically created object, so there is no need to do any manual change to the recorded steps/objects.
The dynamic part in the ID or class name or other attribute is in the middle part like First name: , so I have to use //label[starts-with(@for, ‘field-First_Name_’) and contains(@for, ‘_CF’)] to find it.
Wrong. You’re making this harder than it really need to be.
First, I’m talking about the
Second, even if I was talking about the label for the input (why would I?), it would be as simple as
So let’s pick the ones where the recorder is failing, and let’s fix them manually!
Don’t let yourself become slave to the tool.
So this is the object that is failed: //div[@id=‘st-select__option-61081856673-renewed’]/span
I changed the xpath to //div[starts-with(@id, ‘st-select__option-’) and contains(@id, ‘-renewed’)]. I know //div[contains(@id, ‘st-select__option-’)] or //div[contains(@id, ‘-renewed’)] would work but //div[starts-with(@id, ‘st-select__option-’) and contains(@id, ‘-renewed’)] is more precise and robust.
This XPath expression will select a
On the other hand,
//div[starts-with(@id, 'st-select__option-') and contains(@id, '-renewed')]
this XPath expression will select a
These two XPath expressions will do different thing.
I don’t see if the latter expression is appropriate or not.
My mistake. I changed to //div[starts-with(@id, ‘st-select__option-’) and contains(@id, ‘-renewed’)]/span
Could you post some HTML for that test object, so that we can best advise you on this?
Is there another tag that you can use instead of @id? I have my UI team add a special QA tag for certain objects that are specific and uniquely named. This makes it easier to find the object and not have to deal with dynamically generated id’s. (then again, I also create my own framework and parameterize my objects to be reused. As stated above, record/playback while ok for creating quick simple tests, not helpful in the long run if generating large suites of tests. Maintainability is a nightmare).
I’m surprised there’s no accepted answer for this topic yet… :o
btw, you might want to check out this cheat sheet to learn and help you write xpath!
It has been instrumental in my career as web automation tester, and can add a lot of value to yours!