Working with Scripts

Scripting is a central aspect of SoapUI, allowing you to tailor the behavior of your Test execution to your specific needs. Within the scope of a functional testing, the following scripting possibilities are available:

1. Script TestSteps in a TestCase.
2. Setup and TearDown scripts at the Project, TestSuite and TestCase level.
3. Script PropertyExpansions in any context being evaluated during Test execution. (Read More...)
4. Project-level Event Handlers for events related to Test Execution. (Read More...)

As described in the general overview of scripting in SoapUI, these scripts all have access to context-related variables and a log object, and if you are using ReadyAPI they have full access to your local Script Library. Now let's have a look at the first two in more detail (the other two are covered elsewhere).

The Script TestStep

The Script TestStep is the most powerful TestStep in SoapUI, in the sense that it allows you to do more or less whatever you might need to within the execution of your Tests. The contained script will be executed each time the TestStep is run and can do more or less anything possible with the built in API's available (JRE, SoapUI, all dependencies, etc).

When created the Script TestStep window is as follows:

The arrow at the top executes the current script, the log tab at the bottom shows any log statements written by the script (these are available in the main windows scripts tab when the editor is closed during execution). As can be seen from the label at the top right, the following variables are available in your script;

• testRunner - a TestCaseRunner object (javadoc), which is the entry-point to the SoapUI API for accessing project items, results, etc. The TestRunner is the object that is actually executing the TestCase by cycling through the TestSteps in the TestCase and executing them. It exposes methods related to test execution and the underlying object model (via the testCase property). Common usage scenarios are:
  • using testRunner.testCase to get hold of the containing TestCase from which all other objects in the project can be accessed and manipulated.
  • using testRunner.fail(...) (or testRunner.cancel) to abort the ongoing TestCase when an error occurs.
  • using testRunner.gotoStepByName(...) or testRunning.runTestStepByName( ... ) to transfer execution to another step than the one after the Script TestStep in the TestCase.
• context - a TestCaseRunContext object (javadoc) holding context-related properties. The main usage for this is to store values that can be used in subsequent TestSteps or related scripts. For example
  
  context.myProperty = "Hello"
  
  will create a property named "myProperty" in the context and assign it the string value "Hello". In a subsequent script, you can access it with
  
  log.info( context.myProperty )
  
  A common usage scenario is for looping or keeping track of progress by saving the corresponding counters and collections to the context and using them to control flow as required.
• log - a standard log4j Logger object (javadoc)

Let's have a look at a more complete script:

This script executes another TestCase and displays some result information, optionally failing the TestStep if the called TestCase fails:

• The testRunner is used to access the underlying project model (via the testCase) to get hold of the target TestCase
• If the target TestCase fails, the script throws an exception (via the assert statement), that will fail the containing TestStep. Alternatively a call to
  
  testRunner.fail( runner.reason )
  
  could have been used, but that would have failed the containing TestCase (and not just the TestStep).

Setup and TearDown Scripts

Setup and TearDown scripts are available at all three testing levels in SoapUI; Project, TestSuite and TestCase. In all cases they are managed via dedicated tabs at the bottom of the corresponding Test tab/window, for example in the TestSuite window;

As indicated by their name they are run either before (the Setup Script) or after (the TearDown Script) Test item is executed. Their main usage area is preparing for the test and cleaning up afterwards (closing resources, creating reports, etc). Let's create a small example that creates a JDBC connection at the start of a TestCase and saves it to the context. A Script TestStep in the TestCase uses the connection to perform some kind of database access, and the TearDown script closes the connection nicely for us.

The setup script (using the GroovyUtilsPro class to create a JDBC Connection defined on the project level) is as follows:

A Script TestStep uses the connection for some SQL magic:

And finally the TearDown script saves some more information to the database and then closes the connection for us.

So when we now run the (overly simplified) TestCase, we see

As you can see, we created the JDBC connection and statement in the setup script and saved them to the context, giving us access to them later on in the TestCase for usage and cleanup.

The same objects that are available in a Script TestStep are available here as well; log, testRunner and context. Above that the corresponding object containing the script (testCase, testSuite or project) is available for direct access to it and its related objects.