Forcing a testSuite/Case to end after a fixed amount of time

Product Forums Katalon Studio
1

My team doesn’t utilize Katalon in a traditional QA-testing sense, and more for automating the manipulation of a WebApp. Lately I’ve been given a project where it’s crucial to notify the team when the testCase takes greater than twenty minutes for whatever reason. Sure, I can identify where known loops that don’t terminate at times by comparing time stamps and doing usual error-handling/fileIO, but I was wondering if there was a way to place a hard cap on runtime.

Cheers gents, thanks for reading.

Edit: I know of something that will work, but it’s really disgusting, and it involves encapsulating every few lines in if-statements that compares time stamps. I find when I start doing things like that there’s usually a more elegant way of doing things that I’m not aware of.

2

Haha. Yep. We’ve all been there :wink:

I do something semi-related. The only difference would be, I run a pseudo-test repeatedly for a fixed period (with a resolution accuracy of around ~3mins/9 hours). It’s certainly not the prettiest code I’ve ever written – between the shifting goal posts of the requirements and me stopping once the POC was working, I should probably have rewritten it from scratch – but this is the real world, with no time… I’m still running the POC!

So, I won’t be sharing the code, but I will write out a spec for it. Hopefully, this will get you close:

  1. Let’s call your actual test case “the target”.

  2. Write another test case (“the wrapper”) that wraps the target.

  3. The wrapper uses callTestCase() to run the target.

  4. The wrapper monitors the start time and end time and writes out a report accordingly.

Again, my code will loop around 3 and 4, with another time accumulator watching for 9 or 10 hours to have passed by before setting a flag that terminates the outer loop. Not sure you need that bit, though.

Hope that helps… let me know.

3

Here’s my report output:

URL: https://mrk.somewhere.com/
Total iterations: 158.
Monitor Start time: Tue May 24 23:28:14 CDT 2022.
Monitor End time: Wed May 25 08:31:47 CDT 2022.
Monitor duration: 9 hours, 3 minutes, 32.829 seconds.
Total Failures: 0
Outages: 
[none]
Pulse has finished.
END - 2022-05-25 08:31:47 (CDT)
DURATION - 9 hours, 3 minutes, 32.866 seconds
00 - EXIT TEST
4

I don’t think that Katalon products equip a built-in feature to place a hard cap on runtime.

You can execute a job of Katalon Runtime Engine under Continuous Integration servers.

I found, but not tried myself, that Jenkins can place a timeout over the job. See

Timeout on a Build Step of Jenkins - Stack Overflow

TeamCity provides that feature as well.

How to make a TeamCity build fail (timeout) if it takes too long? - Stack Overflow

You would want to have many jobs to schedule to run automatically. Some of the jobs would run Katalon but you would also have other various types jobs. It would be a good idea for you to use CI servers, which will enable you to control all of them in a single manner.

5

I didn’t think about using callTestCase(). That’s elegant for certain stretches of my testCase, but I’m also realizing I posed my question incorrectly. I’d also need to end the testCase as well should that time limit be hit.

6

Thank you. I’ll pass these along to my lead.

7

Yes, I did understand that:

My guess is, you want to break up your target test into pieces you can call via callTestCase(). You can set time limits on those and abort with a failure if required.

8

Ah, that’s clever. Since I haven’t seen a way to affect the callTestCase() or anything to add timeout in the Katalon documentation directly, so I suppose this “lives” in Java/Groovy land.

Do you use something like this?

http://docs.groovy-lang.org/2.4.9/html/gapi/groovy/transform/TimedInterrupt.html

I haven’t attempted to use a transformation before with Katalon, and assuming transformations don’t upset it, this ought to do it, no? Since the .callTestCase() method would upset it should it take too long.

9

No, I didn’t know about it :blush: But I’d probably take a look at it if I were to rewrite mine.

It’s groovy. It should work. If not, post a question (or bug report).