Good morning nmrao,
Sorry I may have not been clear.
The challenge I have is I have an async call and I want to verify the results of the async call in a subsequent rest call. I have got delays in there that should allow the test to pass but they can be unreliable. So instead I've dropped to a short delay and essentially perform the test step to validate, if it fails it'll jump back to the short delay and retry...
I have this working and once the validate async call step succeeds the test will proceed however it's the fact that some of the earlier retries have failed is leading to the TestCase itself failing, despite the last time through the verify async call step passing...
If that makes sense?
did you get a solution to this ?
I am facing a similar problem where i need to explicitly fail a test step based on a condition (which i have in my trailing groovy script).
Managed to figure out a solution in my context.
Essentially some our API's kick off async operations, for example a POST that kicks off a background process and then I can use a GET to check the status.
What I have done is as follows:
POST API call to kick off the async operation
SHORT DELAY (2 seconds in my case)
An assertionless GET operation
Groovy test step that checks the status from the GET operation to see if I'm now in the right state
If I am then great, proceed
Reset the TestCaseLevelIterationCounter to 1
If I'm not:
I also have a testcase level custom variable called TestCaseLevelIterationCounter - I'll increment that by 1
I also have a GlobalMaxRetries custom variable set to 60
Check if I'm below the GlobalMaxRetries
If I am then go back to my SHORT DELAY test step
If I'm not then fail the groovy test step by calling:
testRunner.fail(testRunner.testCase.name + " - ERROR *** Iteration number: " + testCaseLeveIIterationCounter + " now exceeds the globalMaxRetries: " + globalMaxRetries + " *** ERROR" + " - Was waiting for status HasErrors/Processed and got " + StatusOfItem1Processing + " " + StatusOfItem2Processing);
Now perform my asserted GET to validate the conditions I'm interested in once we're at the desired status.
I'd recommend including the testRunner.testCase.name in there so when you're looking at the script log you know where the outputs are coming from. I also have a log.info message in there as loop through each time showing the counters so you can see if things are running slowly or not.
This worked a charm for me and I have it applied in quite a number of testcases where APIs do things async.
Hope it helps
