Set Text throwing an error

I am testing a web application and recently my SetText has not been working. I call SetText and my application throws an error saying that nothing has been entered. Katalon does not fail at this step though. Katalon seems to think it did set text but in the application it did not. I recently updated to 5.10.1 could this have broken something? I am testing in Chrome and it is up to date. Has anyone else noticed this or is it an issue with my application?

image

Hi,

If all is as you say it is then you have found a bug in Katalon. However, that invites the question, “where are the 1000s of other users complaining of the same problem?”

Clearly, we need to look a little deeper.

Can you provide a Script view shot of the same portion of test case code? A screenshot of the underlying HTML from page might be useful, too.

Thanks.

There are a couple different things that could be happening… The first thing I would check is verify that your “Required Shift Length” object is the correct object you defined. If katalon doesn’t fail the step then its possible it is setting the text of a different element (without errors) that is not visible and not the one you wanted.

If this is not the case… try clicking the element before you set the text or possibly keypress tab. Sometimes fields need to be in focus in order to enter a value into it.

These test cases had been running fine. We test our scripts numerous times before automating so I know this has passed in previous runs. I attached the script view and I confirmed that I am focusing the correct object. I rewrote the script to call SetText, cancel out of the error message, and then try SetText again and that worked. Maybe it is just an issue with our application?

Clicking in before calling SetText produced the same error. And I confirmed that it is correctly identifying the object because the Click worked properly.
I rewrote the script to do a work around where it calls SetText, gets the error, closes the error, and then SetText again. And for some reason that works. Kind of an annoying work around especially when this has never been a problem before. But, I guess if it works then that’s fine. However, SetText does work perfectly fine in other instances. For example, in the original screenshot, the Name field was entered with SetText and it worked fine.

Which suggests to me, your TO is not ready at the time you’re accessing it.

No, it isn’t fine. There’s something wrong and it’s going to show up elsewhere. Besides, if your tests are full of workarounds, you’re having to second guess yourself to such an extent you’ll end up trusting nothing, anywhere.

Which is the big red flag telling you this is the “odd ball” and needs fixing.

Try waiting until the element (TO) is actually visible first (your fixed-length delays are not the best way to handle delay/pause etc, but that’s a different problem for another day).

https://docs.katalon.com/katalon-studio/docs/webui-wait-for-element-visible.html

3 Likes

I should clarify, numerous test cases are experiencing this issue but obviously it is not every instance. I tried the method of Keys.TAB and the method of Wait For Element Visible but neither of them worked. I think you are right about the work around being a bad or temporary solution.

I hate to keep asking but are there any other options that you may know of?

Thank you for all your help!

I have a sneaking suspicion that @Eric_Montou is onto something with:

I know you’ve double checked that you’re getting the correct element, but is it possible for you to share the HTML for the element (and maybe the surrounding HTML, with sensitive information redacted of course), as well as the Test Object you’re using to locate it?

If you are 100% sure you have the right element, a good way to check if this is indeed a Katalon bug would be to do this the old-fashioned way, and see if Selenium can set the text without a problem:

WebElement element = WebUiCommonHelper.findWebElement(findTestObject('TM-Setup- Work Place/Break Policies/Required Shift length'), 30);
element.sendKeys("test");
2 Likes

Not sure if you saw my last comment before I deleted it, but if so, scratch that. The selenium plug did work and did not cause an error.

So do I have to use this selenium fix for all my test cases or was that just a check of sorts?

Seeing as it seems to be a targeting issue with Katalon, have you tried remapping the object you are trying to target? If you haven’t already try mapping just the Xpath of the HTML element to the object. Sometimes other targeting methods can share the same path’s. Xpaths are unique so this type of conflict shouldn’t happen.

  1. Open your website, right click the text field you are trying to set text into, and click Inspect Element
  2. In dev tools right click the highlighted element -> hover over copy -> click copy Xpath
  3. In Katalon open the object, in your case it would be “Required Shift Length”
  4. Click XPath radio button as the selection method
  5. In the Selector Editor text area, paste the XPath you copied and save.

Let me know if that helps at all.

The short answer is, it was just a check, and the issue you are encountering when using the setText() method on this particular element should probably be logged as a bug. The devs would need to see your EXACT test code, as well as a snippet of the HTML for the element, and probably surrounding elements (parent elements). They may ask for more than this of course.

The long answer is that you will need to decide if you want to adopt a general strategy that you will use for setting ANY text going forward, or whether you use that Selenium approach as a patch of sorts for ONLY this element. I’ll tell you what I would do if I were in your shoes, and you can evaluate whether its a reasonable strategy for testing your app(s) going forward.

I would create a Custom Keyword to handle this every time, instead of using the built-in setText() keyword. Your method would look something like:

public void setText(TestObject object, String text) {
       WebElement element = WebUiCommonHelper.findWebElement(object, 30);
       element.sendKeys(text); 
}

You may need to adjust this according to your needs, but this would be a good starting point. Then, instead of calling the built-in setText() keyword in any of/all of your scripts, you would just call this.

3 Likes

I changed the topic of this post to be a bug report. Thank you for all your help.

I’m not convinced this is a bug. I’m not saying this isn’t bug, just saying “we’re not there yet”.

Did you try @Frank_Schiller’s approach?

Did you try something ridiculous like waiting 15 seconds before accessing the element in question (and run the test 5-10 times)?

To me, TestObjects are a huge time-sink. But, they’re the primary means of accessing HTML elements using the standard Katalon OTS toolset. That being the case, you might find using @Brandon_Hein’s approach (or similar) a better move going forward since it relieves you of the burden of managing quirky workarounds in your test case code.

Again, I’m not convinced we have a bug yet, not least because there’s a lack of similar reports (right now, anyway).

But it’s your baby, you’re best placed to know how to deal with it.

Yeah, I hear ya. It may not be a bug right now but I know this was not happening before we updated.

Also I did not do Franks approach as I know for a fact it is not about locating the element. The selenium was able to locate the object, the Click was able to locate the object, and the Wait For Element Visible was able to locate the object.

It is very strange that I am the only one reporting this issue though. Perhaps it has something to do with my actual application and not Katalon. But, for now, I will make a keyword with the selenium as Brandon suggested. And to all of you, I really can’t thank you enough. I have been staring at this ‘bug’ and refactoring test cases to work around it for two days so it was great to hear from helpful people so quick.

We like problems, sickos that we are :crazy_face:

We like solving problems even more :sunglasses:

4 Likes

I think this is the crux of it. That’s why it would be helpful to see the HTML you are working with, to evaluate the actual element in question. I agree with @Russ_Thomas, it may not be a bug at all, but it should be logged as such and investigated further with these details. In either case, I’m glad you’re off to the races without losing (too much) hair. :metal:

1 Like

Sometimes it can be your application. I ran into an issue where setting the text of a field would drop the last keypress entered but only some of the time. I ended up having to set a for loop to keep setting the text until it takes the value I wanted. It seemed like a terrible solution but it was the only way I could get it to work with our application.

I had one of those - a weirdo asp.net derived bag of :poop: with who-knows-what tied to it monitoring keypress AND keyup (just to annoy, I’m sure) and other stuff happening onchange. In the end, I …

  1. Cleared the damned thing via js.
  2. Set the damned thing via js and
  3. Called onchange on the damned thing in js myself.

That fixed the damned thing.

Thankfully, the damned thing no longer exists :skull: \o/

1 Like

Yes I think you are absolutely right. I presented the issue I was seeing to a colleague of mine and apparently some months ago we were seeing a very similar issue to the one I am seeing now. The selenium plug suggestion luckily enough does fix our issue though. Just one of the many pleasantries of software design lol

2 Likes