soapUI: Scripting Objects - WsdlTestSuiteRunner Class

Looking over traffic on past posts, I can see that one of the more popular topics has been the walk-through of data looping using scripting in soapUI, so I thought it might be a good idea to return to the topic in general, and the soapUI API in particular.  By Smartbear's own admission, it's pretty massive-- on the one hand, it's a testament to how much is packed into the program to begin with, but wading through the Javadoc (you can find it here) can get a bit tedious.  In the next few posts I'm going to try to review some of the objects you're likely to be interested in when you begin to use scripting in soapUI.

Obviously, these posts will be far from complete; to avoid biting off more than I can chew, I'm going to limit the discussion to scripting via the "containers" provided in soapUI-- in other words, the Setup and TearDown scripts available at the test suite and test case levels and Groovy Script testing steps.  I'm also not providing constructor methods, the assumption being that objects will be accessed directly or indirectly via the variables (like the runner variable) provided by soapUI.

With each post I'll try to tackle one or two objects and some of their methods.  This week we'll look at the WsdlTestSuiteRunner object.

WsdlTestSuiteRunner Class

A WsdlTestSuiteRunner object is easily accessible in soapUI via the runner variable available in a web service test suite's Setup and TearDown scripts.  As you might expect, it controls execution of the test suite, but it can also be used to access run results and other useful scripting objects.

A few of its methods:

- getResults() : returns a Java List of TestCaseRunner objects (see the post for the WsdlTestCaseRunner class, which is generally what you'll be dealing with) corresponding to the suite's test cases; these can be used in turn to access test step results
- getTestSuite() : returns a WsdlTestSuite object representing this test suite runner's test suite
- getStartTime() : returns the time (as a long) the runner was last started
- getTimeTaken() : returns the time taken (as a long) since the runner was last started
- getStatus() : returns the test suite's run status (as defined in the TestRunner.Status enum type; possible statuses include CANCELED, FAILED, FINISHED, INITIALIZED, RUNNING, and WARNING)

Here's a sample script (from the Setup script for a standard web service test suite called "Object Model Test Suite") that demonstrates some of these methods:

//Demonstrating the object type provided by the runner variable
log.info(runner.toString())
//Getting the runner's test suite
tsMySuite = runner.getTestSuite()
log.info("Name of Test Suite is " + tsMySuite.getName())
//Get test suite run start time
tsStart = runner.getStartTime()
//Convert from long to date format and display
startTime = new Date(tsStart)
log.info(startTime)
//Display test suite status
log.info(runner.getStatus())

Here's the corresponding output in the script log window when the test suite is run:



Here's an example TearDown script:

//Get test suite status
log.info(runner.getStatus())
//Get test suite time taken
tsTimeTaken = runner.getTimeTaken()
log.info("Time Taken: " + tsTimeTaken + "ms")
//Get results as List of TestCaseRunners
lstTCRunners = runner.getResults()
//Iterate through test case runners to get test case info and statuses
for(tcr in lstTCRunners){
 log.info("Test case name: " + tcr.getTestCase().getName())
 log.info("Test case status: " + tcr.getStatus())
}

And the TearDown script's corresponding output in the script log window:

Sikuli IDE: Using Pattern Objects

If you go back to the script illustrated in the last post and look at the code for click() or wait() calls in IDLE or some other IDE for Python (other than Sikuli's own editor), you'll see something like the following:
...
wait("FileEditForm.png",5)
...
click("1351739445615.png")
Beneath all the source images in our script (as displayed in Sikuli's IDE) are strings matching the image file names.  When rendering the script in its IDE, Sikuli interprets these strings as instances of its Pattern object, replacing them with the images they represent.  It's important to recognize that we are not limited to using Pattern objects within click() and wait() calls directly-- we can manipulate them programmatically to make scripts more flexible and/or efficient.

To illustrate, let's say we have an app that looks like this:


When the user clicks on any of the color buttons along the bottom of the app form, the large "Color" text changes to match that color.  A straightforward way of writing a test script would be to write four pairs of click() and exists() methods, with each click() on one of the four buttons followed by an exists() check on the "Color" text (to verify it's displaying the right color).  But keeping Pattern objects in mind we could also organize our script like this:


A Sikuli script with Pattern objects organized in a list

In this script, the Pattern objects (images) are organized into a list of tuple pairs; the first image in each pair is the button being clicked, and the second is the "Color" text as we expect it to appear when each button is clicked.  We can use the image list with a for loop to check all four buttons. Using a list like this opens up other possibilities, too-- for example, we could easily step through it randomly instead of following a set order. Obviously, this is an oversimplified example, but it still reflects a fundamental idea behind UI testing that can be applied to more complex applications: interacting with one UI element (via a click, for example), then verifying expected behavior by confirming the existence (or non-existence) of some associated visual "cue".

A few words about some "gotchas" when working with source images: going back to the example in the first paragraph about file name strings, there's no path information necessary with this particular example because the files are located in the same directory as the Sikuli script.  Of course, if you wanted to put your source images in a different directory, you'd have to add corresponding path information to the file name string.  Be aware that as of build 905 of Sikuli X, moving the images out of the main .sikuli folder for your script can also result in problems with rendering them properly in Sikuli's IDE-- you'll see some errors appear in the Message pane at the bottom of the IDE when loading your script, and where you'd expect to see images you may see the underlying strings instead. Here's what my image list looks like in Sikuli's IDE after moving the images to a sub-directory in the .sikuli folder called "Imgs" (and modifying the script accordingly):

image_list = [("\\Imgs\\EE.png","\\Imgs\\Color.png"),
        ("\\Imgs\\1354395248414.png","\\Imgs\\C0l0r.png"),
        ("\\Imgs\\1354395299725.png","\\Imgs\\C0l0r-1.png"),
        ("\\Imgs\\1354395332765.png","\\Imgs\\C0l0r-2.png")]

The script still runs successfully, but the images themselves are not loaded and displayed in the IDE.

One alternative way to deal with source images located in directories other than the .sikuli folder is the addImagePath() method.  Sikuli maintains an image search path-- a list of directories that it will search when a given image can't be found in the active .sikuli folder.  So for example, if you moved an image into a directory called "C:\Temp\Images", you could just add the directory to the image search path using the following code:

imgPath = list(getImagePath())
if 'C:\\Temp\\Images' not in imgPath:
    addImagePath('C:\\Temp\\Images')

Subsequently, the full path for any images in that directory would not have to be specified-- you could just specify the image file name by itself; Sikuli would automatically include the "C:\Temp\Images" directory when looking for the image.  Note that while this method does save some time typing out paths when specifying images, it may still result in the same problems explained above when using non-.sikuli folders for images.

Sikuli IDE: A Basic Walkthrough

This is a brief Windows-oriented tutorial that walks through a Sikuli IDE test script (there are tutorials provided on the Project Sikuli site, too).  This script demonstrates how to create and manipulate the Sikuli App object and perform some basic UI actions using the Notepad application.

Here's the starting point for your script:

NPPath = 'C:\\Windows\\notepad.exe'
#Open Notepad using the App object
NPApp = App.open(NPPath)
#Wait until the menu bar is visible, then display message
#that the window is open.
wait("Your Notepad Menu Bar",5)
popup("Window is open!")
menuBar = getLastMatch()#Takes advantage of wait function side effect
#Highlight the menu bar region for 3 seconds then click on text
menuBar.highlight(3)
menuBar.click('Help')
#Define a new region using 'Help' text as starting reference
dropDownRegion = Region(menuBar.getLastMatch().getX(),menuBar.getLastMatch().getY(),300,100)
dropDownRegion.click('About')
wait(3)
click("Your OK Button")
type("This is a test message")
wait(3)
NPApp.close()

Open Sikuli IDE and paste this into the IDE window.  You'll be unable to run it as is, though-- you need to supply at least two graphic elements: the Notepad menu bar and the Notepad About dialog OK button.  Highlight the text "Your Notepad Menu Bar" (including the quotes) in line 6 and, with Sikuli IDE still open, launch Notepad.  Press CTRL + SHIFT + 2-- you should see your screen "fade" slightly as Sikuli IDE enters its capture mode.  Click and drag the cross-hair across the menu bar items-- it should look something like this:


Capturing the menu bar

When you release the mouse button, the screenshot of the menu bar should automatically get inserted into the script:


Script with menu bar screenshot pasted

In Notepad, click Help in the menu bar, then "About Notepad" and repeat the steps above, this time replacing the "Your OK Button" text near the bottom of the script with a screenshot of the OK button in the About Notepad dialog.


OK button pasted in

Now try running the script (note that when the "Window is open!" message is displayed, the script is paused until you click the OK button).  Also make sure the path to Notepad is valid for your particular version of Windows (the script was written on a PC running Windows 7).

Now let's step through the lines of the script; if you're experiencing problems I'll try to highlight some "gotchas" as we go that might be the source.

In the first few lines of the script we're opening Notepad by creating a Sikuli App object-- the App.open() function does this using the path to your target application.

Sikuli's wait function (line 6) scans the screen for the existence of the indicated (text or graphic) element; the second parameter indicates how long Sikuli should wait (in seconds) for the element to appear before failing (you can use the constant FOREVER to specify that Sikuli should wait indefinitely)-- here we're giving Notepad five seconds to launch.  If you have a particularly slow machine where it seems to be taking a while for Notepad to launch, try upping this wait time parameter.  There's a corresponding function in Sikuli called waitVanish()-- this function behaves similarly to the wait function, but scans the screen for the absence of a given element (i.e., waits for it to vanish from the screen).  Other similar functions: find(), which (no surprise here) simply finds the given element onscreen without acting on it; click(), which we'll see below and finds and clicks on the specified element; and exists(), which checks for the presence of an element onscreen.

The popup() function (line 7) simply displays a message box with the indicated text-- as I mentioned previously, Sikuli will pause after the popup is displayed and wait for the user to click the OK button before continuing.  This can be useful for troubleshooting scripts or pausing the script to allow for a manual task.

In line 8, the menuBar region is retrieved using the getLastMatch() function-- this illustrates a useful side effect of many of Sikuli's basic functions, including the wait() function-- when the function is successful (e.g., the element that wait() is waiting for is detected) the location of the element is stored as a match that can be retrieved later via the getLastMatch() function.  So in the case of our script, once the wait() function in line 6 is successful, it's not necessary to re-find or otherwise identify the menu bar pattern (which can be a costly operation in terms of processing resources).

In line 10, the highlight() function is called for the menuBar region we just defined, which simply highlights the region for the given amount of time (in seconds).  This can be useful for troubleshooting scripts in instances where you're dynamically defining a region that's supposed to contain a specific element-- you can use the highlight to see what's actually included in the region.  A word of warning about the highlight() function, though:  I've seen cases where it may result in a redraw that "hides" some child windows (like drop-downs, for example).

In the next line, text recognition is used to identify the Help button in the menu bar and the identified area is clicked.  As I mentioned in my previous post, Sikuli IDE's text recognition can be a little finnicky sometimes.  If you seem to be having problems with this particular action in the script, try using a graphic element (an actual screenshot of the File button, captured as described above) instead of text.  Text recognition seems to work best for cases like this: a short string with a simple well-contrasted setting (e.g., black text on white).

One more important thing to point out in line 11 is the use of click() as a method of the menuBar region.  When functions are called as methods of regions, Sikuli only scans those regions, not the entire screen.  In fact, in line 6 of the script when we called the wait() function without specifying a region, it's called as a method of the default SCREEN region-- a region encompassing the entire screen.  Generally it's good practice to call these functions on regions instead of the entire screen since it's less costly to scan a subsection of the screen as opposed to the entire screen.

Line 13 defines a new region dynamically.  A Sikuli Region object's area is defined by four parameters-- x and y coordinates that define its upper left corner, and width and height parameters.  In this line in the script we're using the getLastMatch() function again, this time for the menuBar region.  The click() function in line 11, also called for the menuBar region, recorded the location of the "Help" text as a successful match; getLastMatch() returns it.  Using the match as our starting point, we can define a new region by getting the X and Y parameters of the "Help" text's region-- via getX() and getY()-- then making our new region 300 pixels wide by 100 pixels tall.  This line could cause problems depending on your computer's resolution-- if you find that the next line is failing (even after ruling out a text recognition failure) try making the region larger in this step-- it could be that the 300 by 100 pixel region is too small to encompass the About Notepad button.

The last few lines are self-explanatory or repeats of functions we've already seen: Sikuli finds and clicks on the text "About" in the newly defined dropDownRegion, then waits for 3 seconds as the About dialog is displayed.  After three seconds, the OK button is identified (via a screenshot this time, not text) and clicked. The text "This is a test message" is typed into Notepad's main window and finally, after a 3 second wait the app is closed using the App object created in line 3.

Of course, this is a very simple script and only illustrates the tip of the iceberg of Sikuli's power.  If you're interested in a more detailed look, I recommend checking out Sikuli's documentation (which I think is pretty well-written) here.