Not seeing script mode for a Test Case


I used to write keywords like this

public static TestObject getSharedSyncIconForFile(String name){...}

But i was told I’m supposed to write kewords like this

def getContextMenuForFile(String name){..}

But after reformatiing the keywords my test case did not recognize the keywords.
While trying a few things, I did the following with the test case, because it made sense to me for some reason

But after doing this, I can no longer see the Script mode for the test case. How do I get it back?

I don’t know what you’ve done to your test(s) but, just for clarity, this…

is perfectly fine. I write mine like that.



is only required if you want to see your methods listed in Manual View. If you’re happy working in Script View, stick to your original plan.

If they’re both the same why wont katalon recognise the keywords after I changed them?
Let me try to clarify:
I sent my code for review with the functions written with public static. But they told me no, no you’re not supposed to write keywords like that, in Katalon we write them with annotation and def
I was assured that nothing will happen if you change the way you write them, so please adhere to what everyone else is doing. So I was like ok fine and changed all the functions to look like @Keyword def …
But now when I went back to the test case to run them, all the functions were underlined, like Katalon could not recognise them for some reason. I refreshed the project, closed and opened Katalon, but they are still underlined
This is when right-clicked on the test case and found the option Convert file extension to java(like in the screenshot I posted in the OP). I dont know, I was trying many things and I just tried this and boom! the script mode for the test case disappeared. Why?
At this point, I’m just rewriting the test case with a new file because I find this behavior to be quite weird and I dont waste too much time. But I do want to find out whats going on.

They’re not both the same. See my earlier post.

Who are “they”?


You possibly caused the files to be renamed (*.java perhaps?). Now KS can’t find them.

The behavior seems weird because you’re trying random things without learning the potential outcomes before trying them. The amount of time you’re “wasting” could have been spent reading the documentation or asking here on the forum, first.

Ok, thank you. I will keep these points in mind.
In my reply there’s a typo. I meant to type I dont want to waste too much time. I come off as a jerk with the typo.
Who are ‘They’? Well, you know, they. The powers that be.
In this case its the person who reviewed my code. I’m fairly new and learning as I go along. For some reason he did not like public static, he kept saying static causes memory issues. He also does not like explicit delays, for the most part I can remove them though. He says something like explicit waits are bad practice, but I cant understand why.
Thanks again for the advice. I was a bit desperate because all the work I did looked like was for nothing. I apologize if I sounded rude and I appreciate the input.

He (and you) should remember the lifetime of your testing code – it’s not an application that needs to run for months at a time. There are many “optimal” programming choices you would make in any other system that do not apply (or do not carry the same weight) in testing code which runs for minutes or, less often, many hours but certainly not days or weeks…

They’re rarely good. But if you need to “poll” a resource in/on another system (a browser, say) they are THE choice.

Firstly, beware those that preach “good” and “bad practice”. Most of that “information” is “received wisdom” rarely backed by sound engineering and scientific analysis. Also, good and bad practice are moving goal posts. Aim for measurably good and sound engineering.

Why using a fixed delay can prove problematic – consider the following scenario:

The page responds to a certain click by requesting more data from a server. You are to write a test that ensures the data request works and the page updates to reflect the change with new data. You notice that your test runs too fast, that the request takes up to 5 seconds to retrieve the data and present it on the page to the user. “Simple, I’ll just add a 5 second fixed delay. Or 6, just to be sure.” Great. It’s working!

Now you move your tests to another PC on a different network perhaps with a different server. You have 100 fixed delays spread throughout your code. This network is bursty. Sometimes quick. Sometimes slow. 75% of your fixed delays no longer work.Then they work again. Then they don’t.

Congratulations. You’ve just cornered the market on flaky tests :stuck_out_tongue_winking_eye:

That’s not bad practice. That’s using the wrong tool. Network timings don’t follow fixed delays. Don’t use them in your code to fix varied timings

No problem.

Back to your real problem – search on disk for your scripts. Find out what happened to the filenames.

1 Like