Stop and mark test case as error from listener

I have a test case listener that, in the method under the @BeforeTestCase annotation, reads through an external file to obtain information. I am wondering if it’s possible to stop execution of the test case and mark it as an error from a catch block on the event of an error, e.g. file not found. I’ve tried KeywordUtil.markErrorAndStop in the catch block of the listener, but the test case execution will still begin regardless.

Also want to note that I do have an available workaround of sorts with KeywordUtil.markError followed by System.exit, but this isn’t very elegant and it won’t actually mark the test as an error.

Hi Michael

That sounds a little buggy to me - you might want to post a bug once you’ve “tried everything”.

However…

Recently I bumped into an issue in a suite listener. At the time I was pressed for time and didn’t get to resolve the actual cause. The problem I had was setting a Map key for the suiteId. The Map was static, imported statically but it seemed the listener couldn’t see it. Like I said, I was pressed for time so I ended up calling a method (on the same damn static class - go figure) to set the Map directly in the class. (I’m saying, if Kat couldn’t see the Map, it shouldn’t have been able to see the method, either, but it worked).

Perhaps you could try the same approach.

Alternatively, did you try throw after the markError? That would definitely stop the test (not sure about the markError surviving that though). Try it. Might work.

Hi Russ,

I’ve tried a throw, but it’ll still proceed with the test case afterwards.

One observation I’ve noticed is that markErrorAndStop will return control to the test case and not execute any more code in the listener:

throw new StepErrorException("An error was encountered while reading the data file, etc...")
//Keeps running...
KeywordUtil.markErrorAndStop("An error was encountered...")
//Anything below here will not execute

markError, however, will allow additional lines of code to execute. I guess markErrorAndStop assumes it’s being called directly from the test case rather than a listener or keyword.

I could theoretically put a check in the TC itself for a variable to be set from the listener, but this is clunky and I’d need to add it as a step to every single case that depends on the data file. Still, I might not have a choice.

Of course, I should have known that…

Your code in the Test Case is a method (in a Groovy Script class). Your “final” throw has to come from there to stop it in its tracks. Sorry, I really missed the point back there.

For reference, this is how my TCs look:

import ...

public class Test extends com.my_company.some_page_object {
  
  Test() {
    // Test steps ...
  }
}

try {
  new Test()
  passThisTest()
} catch(Exception e) {
  failThisTest(e.message)
}

So anywhere I perform a throw (or any throw issued by kat code), I get to catch it, deal with the message my way (I write my own reports for example) and then my script method ends.

So it does look like you need to set the stage in the listener and deal with it somewhere in the TC runtime scope (if that makes sense). This also might have been my issue I didn’t investigate properly.

Anyway, hope that gives you food for thought.

1 Like

No worries.

I’ve been able to make something that does work, though it uses a static method inside a keyword groovy script (or is it Java?):

public static String write(int inputNum) {
		try {
			String input = values.get(inputNum.toString())
			return input != null ? input : "### Invalid Input ###"
		}
		catch(NullPointerException) {
			KeywordUtil.markError("An error was encountered while reading the data file. Please ensure the file values.csv exists and is readable.")
		}
	}

“values” is a static Dictionary that is populated by my listener if nothing goes wrong while accessing values.csv. If something blows up, then values remains null, and as such, the write() method will throw a null pointer exception once called. This ends up marking the test as failed (close enough) and does not execute any more steps in the TC. While I’d like to avoid starting the TC at all, this is the best result I’ve seen yet.

1 Like