Forum Discussion
Hi kenm,
I'm not 100% sure if I follow, but I think I might understand.
When I do my "has the async call completed" check (Step 4 in my post above), if it hasn't completed, I don't actually fail the test, I just use the gotoStepByName("Test Case Name") functionality to jump back to the delay step, which will then rerun the check after the delay, the only additional thing I do is write a log file message to say I've jumped back. I usually set my delay times so on average the retry loop will take about 2 or 3 loop backs before the async call is completed.
I only actually fail the test if my retry loop reaches some abritary high limit that means something serious has gone wrong and it will never complete, usually about 20 retrys.
Hope that make sense?
Note that in my example I am separating out the verifying that the async call has completed (step 4) and has the async call actually done what I want it too (step 5).
Thanks Radford,
That's the issue I'm trying to overcome/presenting me issues.
I.e. my "wait until async call is complete" includes assertions... so I'll either need to figure out a way of working around that or adopt same approach as yours and verify without assertions so we don't trip it into a testcase failure state.
Time to do some more digging... really appreciate your time/thoughts here so far!
- Radford8 years agoSuper Contributor
As always, there will be lots of ways to solve the problem. Just one more suggestions that may or may not help.
Have you seen the Assertion Test Step? You could remove all of the assertions from your "Verify the Status of the automation request", just checking if the async call is complete in a Groovy test step, then use a assertion test step after the retry loop. I think this might be the most out-of-the-box solution, allowing Ready API to take care of all the checking and reporting on assertions.
Related Content
- 6 years ago678
- 2 years agoM_Schofer_1111
Recent Discussions
- 4 days agominhng