soapUI: Scripting Objects - WsdlTestCaseRunner Class

This is a continuation of a series of posts attempting to review some of the objects (and methods) you're likely to encounter when you start scripting in soapUI.  To see the full soapUI javadoc, click here.

WsdlTestCaseRunner Class
The WsdlTestCaseRunner object is analogous to the WsdlTestSuiteRunner object at the test case level.  A WsdlTestCaseRunner object for each web service test case is accessible directly via the testRunner variable available in test case level Setup and TearDown scripts and Groovy Script test steps; another common way of accessing it is through the WsdlTestSuiteRunner getResults() method (which returns a list of test case runners).  Through the WsdlTestCaseRunner object, you can control execution of a test case (altering the order in which test steps are executed, for example) and get test results.

Some of its methods:

- getResults() : returns a Java List of objects representing results for the test steps contained in the test case
- getTestCase() : returns a WsdlTestCase object representing this test case runner's test case
- getStartTime() : returns the time (as a long) this test case runner was last started
- getTimeTaken() : returns the time taken (as a long) since the test case runner was last started
- getStatus() : returns the test case's run status (as defined in the TestRunner.Status enum type; possible statuses include CANCELED, FAILED, FINISHED, INITIALIZED, RUNNING, and WARNING)
- gotoStep(int index) : designates the test step at 0-based index index as the next step to be executed; note that execution is not immediately passed to the designated test step-- the current step will complete execution first
- gotoStepByName(String name) : designates the test step with name name as the next step to be executed; execution is not immediately passed to the designated test step
- runTestStepByName(String name) : runs the test step with name name and returns a test result; note that unlike the goto... methods above, the runTestStepByName() method will cause execution to pass immediately to the designated test step and return execution back to the step where it was invoked

Let's take a look at some examples.  Let's start with this sample test suite (a modified version of the test suite used in my data looping post:


The ElementSpecificRequests test case has the following Setup script:

//Get start time and test case name from the runner
startTime = new Date(testRunner.getStartTime())
log.info(testRunner.getTestCase().getName() + " started at: " + startTime)
//Get test case runner status
log.info("Runner status: " + testRunner.getStatus())
//Run Groovy3 Test Step-- returns a result
groovy3Result = testRunner.runTestStepByName("Groovy3")
log.info("Back in Setup: Groovy3 Result " + groovy3Result.getStatus())

Here's the Teardown script:

//Get time taken and runner status
log.info("Status: " + testRunner.getStatus())
log.info("Time Taken: " + testRunner.getTimeTaken() + "ms")
//Get and list step results
listStepResults = testRunner.getResults()
for (res in listStepResults){
 log.info(res.getTestStep().getName() + " : " + res.getStatus()) 
}

The scripts in the SkipGroovy, Groovy2, and Groovy3 steps simply announce that they're running by writing a line to the script log, but the Groovy1 step contains this:

//Illustrates gotoStep
log.info("In Groovy1; executing gotoStep(2)...")
testRunner.gotoStep(2)
log.info("Still in Groovy1 step!  Goto is not immediate...")

The output when this test suite is run is:



There are a few things worth pointing out in the scripts and log output.  First, take a look at lines 3 and 4 in the script log (starting with "Groovy Step Groovy3 is executing!")-- these correspond to the lines (starting at line 7) in the Setup script where the runTestStepByName() method was called.  Note that in this case the Groovy3 step is run immediately for a result (passed back by the method) and then execution continues in the Setup script.

Compare this with the behavior of the gotoStep() method called in line 2 of the Groovy1 test step.  The method calls the step at 0-based index 2 (for those unfamiliar with the terminology, 0-based essentially means you start counting at 0 when counting items in the list-- the first item is at index 0, the second at index 1, etc.).  The step at index 2 corresponds to the Groovy2 test step, but execution is delayed; you can see the the final line of the Groovy1 script is executed before the Groovy2 script begins.  Also note that the GroovySkip step is skipped altogether-- after execution is passed from Groovy1 to Groovy2 it continues on as normal from there.

Finally, if you look at our step results (starting at line 11 of the script log: "Groovy3 : OK"), you'll see that the Groovy3 step appears twice.  That particular step was run twice (called once from the Setup script and run again as part of the normal step sequence); consequently, both run instances are reflected in our list of results.