soapUI: Scripting Objects - Working with Test Steps


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.

Common Test Step Methods

SoapUI test cases can contain a variety of test steps; accordingly, there are a number of test step classes you'll encounter in scripting.  There are no variables like the testSuite or testCase variables available for test step objects in scripts; you can use WsdlTestCase methods like getTestStepList() or getTestStepByName() to access them instead.  This post covers some key methods (primarily dealing with properties) that are available for all test step classes.  Note that the properties we're dealing with here include "built-in" properties-- i.e., properties that aren't created and named by the user (like test case or test suite properties used in property expansions) but properties that are specific to different test step types.  Here are some of the methods common to all test step classes:

getName() : returns the name of the test step as a String
- getTestCase() : returns the test step's test case as a WsdlTestCase object
getPropertyList() : returns a Java List of TestProperty objects corresponding to the test step's properties
getPropertyAt(int index) : given an integer representing the zero-based index of a property in the test step's list of properties, returns a TestProperty object corresponding to that property
getProperty(String name) : returns a TestProperty object corresponding to the property with name name
getPropertyValue(String name) : returns the value of the property with name name
setPropertyValue(String name, String value) : sets the value for the property with name name to value value

Here's a sample script that displays information in the script log for a SOAP Request test step:

firstTestStep = testCase.getTestStepAt(0)
log.info(firstTestStep.getName() + ":")
log.info("     Class = " + firstTestStep.getClass().toString())
log.info("     Parent Test Case = " + firstTestStep.getTestCase().getName())
log.info("Test Properties:")
stepPropList = firstTestStep.getPropertyList()
for(i in stepPropList){
 log.info("     " + i.getName() + " : " + i.getValue())
}

The script log output:



Note the listed test properties (Endpoint, Username, Password, etc.) are all intrinsic properties for SOAP request test steps-- none of these were created by the user.

Test Step Results

You can access test step results via the WsdlTestCaseRunner class's getResults() method.  There are different step result classes corresponding to different test step types; fortunately, a lot of key results information is available through methods common to all of them:

- getTestStep() : returns the test step (as a TestStep object) corresponding to this result
- getTimeStamp() : returns the time the test step was run (as a long-- see the example below for how to convert from a long to a date/time)
- getTimeTaken() : returns the time taken in milliseconds (as a long) to run the test step
- getStatus() : returns the run status of the test step (as defined by the TestStepResult.TestStepStatus enum type; possible values for status include CANCELED, OK, FAILED, and UNKNOWN)
- getSize() : returns the size of response content in bytes (as a long); for non-request test steps (property transfer steps, for example) this is 0
- getMessages() : returns messages generated by the test step

Here's the tree for a sample test suite:


Here's a sample TearDown script that gathers step results and logs info:

//Get Results
tsResults = testRunner.getResults()
for(i in tsResults){
 log.info(i.getTestStep().getName() + " :")
 log.info("   Class: " + i.getClass())
 tStamp = new Date(i.getTimeStamp())
 log.info("   TimeStamp: " + tStamp)
 log.info("   TimeTaken: " + i.getTimeTaken())
 log.info("   Size: " + i.getSize())
 log.info("   Status: " + i.getStatus())
 log.info("   Messages: " + i.getMessages())
}

The resulting output (only the beginning of the output is shown here to save space and avoid repetition):



Note that the step results for different step types represent different classes, but these methods work for all of them.  The PropertyTransfer1 test step also generates its own message, confirming the successful completion of the transfer.

4 comments:

  1. I tried above code but its not writting any logs. tsResults = testRunner.getResults() i think tsResults is BLANK.

    ReplyDelete
    Replies
    1. Sorry you're having some problems with the sample code. To quickly check the contents of the list variable (tsResults), you can also simply try "log.info(tsResults)"-- this will only print out a list of class names and addresses, but you can at least confirm that something's in there.

      Do you see any info in any of the logs? This may not be the problem, but if this code is in a Groovy Script step, you can't run the Groovy Script step by itself-- if you're trying to run a single step within a test case, there won't be any results to report.

      You can contact me via the contact form or post the problematic code here if you continue to have problems.

      Delete
  2. Hi Mike,

    I've tried the above code and no Log output, its blank. Can you help me.

    ReplyDelete
    Replies
    1. Where exactly are you entering the code (as a tear down script, etc.) and how are you running it? As I noted in response to the preceding post there are multiple run buttons in the UI-- one for a script, one for a test case, one for th suite, etc.-- and the code collecting test results is dependent on the context in which it's run (if you run the step by itself there are no results to collect and report).

      Delete

Please be respectful of others (myself included!) when posting comments. Unfortunately, I may not be able to address (or even read) all comments immediately, and I reserve the right to remove comments periodically to keep clutter to a minimum ("clean" posts that aren't disrespectful or off-topic should stay on the site for at least 30 days to give others a chance to read them). If you're looking for a solution to a particular issue, you're free to post your question here, but you may have better luck posting your question on the main forum belonging to your tool's home site (links to these are available on the navigation bar on the right).