Beginning soapUI Scripting 3: Setup and Tear Down, Context Properties

You can download a "shell" project to import into soapUI and use for scripting here.

In all the scripting we've done up until this point, we've worked exclusively with Groovy Script test steps.  It's time to introduce some more of soapUI's scripting components: setup and tear down scripts. These aren't test steps per se; rather, they're special scripting components available for test cases and test suites through their editors.  The screenshot below shows the buttons to access a test suite's setup and tear down scripts highlighted in blue (the buttons are in pretty much the same place in the test case editor):


At the test suite level, setup scripts are run prior to any of the suite's test cases and tear down scripts are run after the last test case is completed.  At the test case level, setup scripts are run prior to any of the test case's test steps and tear down scripts are run after its last test step is completed.  The resulting order (assuming each component exists): 1) suite setup, 2) test case setup, 3) test case test steps, 4) test case tear down (steps 2 through 4 are repeated for any additional test cases), 5) suite tear down.

Now that we have different scripting components, let's consider the problem of sharing variables between them.  You might want to do this for the purposes of looping (for a counter variable, for example), when working with a file whose contents need to be re-used among components, etc.  By default, variables created in one component aren't available in others.  For example, put the following code into a test case setup script:

def myVar = 1
log.info("In test case setup: myVar = $myVar")

And this in one of the test case's test step:

log.info("In test step: myVar = $myVar")

This code creates a variable called myVar in the test case setup script and prints out a message with its value (for more details about how this line works, see the previous post on strings).  The intention with the test step is to print out the same value using the same variable.  If you try to run this test case, though, it fails.  The setup script message appears in the script log as expected, so the variable seems to be created successfully:


The test step message never gets written to the script log, however.  If you look at the error log, you'll see a message that looks something like this:

Mon May 13 23:11:24 EDT 2013:ERROR:groovy.lang.MissingPropertyException: No such property: myVar for class: Script1

Basically, our test step doesn't recognize myVar.  In the script's current form, myVar only exists in the test case setup script, so it's unavailable to any other component-- you'll encounter an error even if you try to access it from the test case teardown script.

This is a situation where the context variable comes into play.  Like the log and testSuite or testCase variables, context is a built-in variable automatically made available by soapUI; it's indicated in the messages above script windows-- e.g., the "Setup Script is invoked..." message in the test suite editor screenshot above.  You can add your own user-defined variables as properties of context objects (for those of you familiar with user-defined test case and test suite properties, context properties are not the same thing).  This can be done explicitly via the setProperty() method, but you can also treat your variable as a property using dot notation.  Hopefully an example might clarify.  If you put this code in a test case setup script (remember, the lines starting with "//" are comments for clarification-- nothing's executed by the Groovy interpreter):

//Creating a context property via setProperty() method (the long way)
context.setProperty("myString", "Hello World!")
//Creating a context property via direct dot notation (the short way)
context.myString2 = "Hello World (again)!"

And put this into a Groovy Script test step within that test case:

//Getting a context property via getProperty() method
log.info(context.getProperty("myString"))
//Getting a context property using direct dot notation
log.info(context.myString2)

You'll get the following log output:



A few things to note about this example: the context properties are available between components at different levels, created at the test case level but accessible at the test step level.   Also, context.setProperty("myString", "Hello World!") and context.myString = "Hello World!" are functionally equivalent, as are context.getProperty("myString") and context.myString.

The context variable at the test case and test step levels seems to reference the same object; the context variable at the test suite level references a different object, but context properties set in the test suite setup script are still subsequently available at the test case and test step levels.  For example, you could move the test case setup code above to the test suite setup script and you'd still get the same log output.  However, note that while context properties appear to propagate downward (from test suite to test case and test step), they don't propagate up-- context properties created in a test case or test step will not be available with the context variable in the test suite tear down script.