In part 4 of this series on new features in soapUI 3.0 (now 3.0.1) I'm going to showcase some of the features available both in the open-source and Pro versions (the last post was soapUI Pro only), namely JavaScript support in scripts, Project-level TestSuite execution, WS-ReliableMessaging support, integrated WebBrowser and Deploying MockServices in WAR files. Hop right in and enjoy!

JavaScript support

Groovy has been the only scripting language available in soapUI since version 1.6 (ages ago!!), but we have gotten increasingly more inquiries on the support of other script languages, mainly Javascript, python and perl. For this version we have thus integrated the Mozilla Rhino Javascript engine in soapUI, giving you the possibility to use Javascript instead of Groovy as your project scripting language. Thus if you change the Project-Level "Script Language" property to JavaScript, this will affect all scripts in your project, including

- Dynamic property expansion
- Event Handlers
- Setup/TearDown scripts
- etc..

The only exception is the Global Script Library which is still groovy (allowing you to mix groovy and javascript, finally).

So why would you want to use JavaScript instead of groovy? I can think of two major reasons:

1) You already know javascript and don't want to learn groovy
2) You want to create/parse XML in your scripts by using the ECMA-357 ECMAScript for XML (E4X) extensions (very cool)

I'm a real addict to all the syntactic sugar and cool features in groovy, so for me only the latter of the two could be a possibility (and a very valid one!), but just to highlight the differences here have a look at the following groovy script:

testRunner.testCase.testSuite.project.testSuites["Another TestSuite"].
   setPropertyValue( "prop", "value" )

which in javascript this becomes

testRunner.getTestCase().getTestSuite().getProject().getTestSuiteByName( "Another TestSuite" ).
   setPropertyValue( "prop", "value" );

(not much of a difference, I know, but I really prefer to write as little as possible, which is spelled L A Z Y).

Groovy has a multitude of cool integrations with the Java language which make it a better choice for "general purpose" scripting (check out their User Guide for an overview), but the JavaScript engine does have one extremely powerful feature up its sleeve; the E4X extensions for handling XML. These are exceptionally cool and really useful in soapUI, for example to create a response message with a script you would code as follows:

var now = new Date().toString();
var xml = new XML();
xml =
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:sam="http://www.example.org/sample/">
   <soapenv:Header/>
   <soapenv:Body>
      <sam:search>
         <sessionid>{context.expand( "${#TestCase#sessionId}" )}</sessionid>
         <searchstring>{now}</searchstring>
      </sam:search>
   </soapenv:Body>
</soapenv:Envelope>

If you set this as the content of a Script TestStep the last expression ("xml") will be the result of the script, so in a Request (or any other content supporting property-expansion) you can use

${Script Step#result}

which will get replaced by the created XML string.

Another nice thing is the support for namespaces and tree traversal; let's parse a response:

var xml = new XML( context.expand( "${search - Request 1#Response}" ) );
var soapns = new Namespace('http://schemas.xmlsoap.org/soap/envelope/');
var fault = xml..soapns::Fault.faultstring;
log.info( fault );

Here you can see the beauty; GroovyUtils/XmlHolder is not needed at all and the namespace support ensures that we can easily parse complex messages. Wow!

There are a lot of tutorials out there for E4X, check out mozillas own at https://developer.mozilla.org/en/E4X_Tutorial.

If you want to return some value from your script set it as the last expression; for example if we wanted to return the faultstring above we would just end our script with the line

fault;

A future release will allow you to select script-language on the script-level, bear with us for now.

Running all TestSuites in a Project

Before soapUI 3.0 you could not run all your TestSuites at once from inside the UI (well, actually you could in soapUI Pro, but it wasn't very obvious); you would have to use the command-line runners for that. Fortunately, this is now possible in the Project window; double-click your Project Node and you'll get a "TestSuites" tab in the opened window with a runner toolbar at the top and a TestRun log at the bottom:

This is more or less the same as the TestSuite window containing a list of TestCases; you can run, reorder, enable/disable, etc your TestSuites and also specify setup/tearDown scripts that will be run at the project level. soapUI Pro-users will note that the Project Coverage functionality in 2.5.x has moved to a corresponding tab here instead.

On a side note, soapUI 3.0.1 updates the command-line runner integration (available from the Project/TestSuite/TestCase/LoadTest menus) so that it (finally) supports all options available, making it easier to set up the correct commands and trying them out [Read More in the User-Guide].

Rely on your messaging with WS-ReliableMessaging

WS-ReliableMessaging is one of those cool WS-* standards that will take any dinner-party conversation into uncharted territory. The new WS-RM support in soapUI thus allows you to easily test services that require/use this QoS functionality, available at two levels in soapUI;
- Request level : creates a WS-RM conversation for a single request
- TestCase level : create a WS-RM conversation for each endpoint called during the run of a TestCase

The first is available from the WS-RM inspector in the Request editor:

The second is available from the TestCase Options dialog:

Enabling either of these will create WS-RM sequences/transactions for the corresponding request(s) to correctly invoke the target service (Stay tuned to my blog, a tutorial for WS-RM is in the making).

JXBrowser Integration

To provide correct HTML previewing functionality in soapUI, we chose to integrate an external browser-component; JXBrowser from the folks at TeamDev. JXBrowser basically wraps the Mozilla/Firefox engine, so using it we can now provide accurate rendering of HTML pages, Flash-movies, etc (basically any content supported by the xulrunner engine). In soapUI, this is available in the response message view for REST and HTTP Request Steps; to see it in action try adding an HTTP TestRequest step to an empty TestCase as follows (specify http://soa.sys-con.com/node/1064221 as the URL);

In the opened editor, run the Request and in the Response view select the HTML tab, voila:

You can click links and navigate in the browser as you would be able to in a standalone browser; external windows will be prompted to open using the system browser instead). Obviously this is a nibble at the possible functionality we can add for functional website testing, but lets not go down that road quite yet

Just to see a flash-movie in action, change the endpoint to http://www.adobe.com/devnet/flash/samples/drawing_1/1_coordinates.swf;

JXBrowser works well on 32-bit JREs under Windows and Mac, but might give issues on some Linux distributions, if you need/want to disable it add -Dsoapui.jxbrowser.disable=true to the soapUI command-line invocation or .vmoptions file.

Deploy As War

Here comes a last-minute goodie that made it into 3.0.1; the possibility to deploy your MockServices as a WAR-file under your favorite servlet-container. It's quite easy actually; right-click your project and select "Deploy as War", which opens the following dialog:

Set the desired options and specify the target directory and war file, pressing OK will churn a bit a create a WAR-file containing everything required; drop this war into your webapps directory of something like tomcat and off you go; Specify /<webapp>/<MockServicePath> as your endpoint path and you can call your MockService as usual, but with all the benefits of running under a "real" container; SSL support, restarting, etc.

Pleas note that this is experimental functionality with some initial limitations at hand, mainly the lack of support for composite and encrypted projects, the groovy script library is not included, and the generated WSDL's will not have correct endpoints set for the service and includes/imports (all to be ironed out in the upcoming builds). Anyhow, please let us know what you think and help us push it forward in the right direction.

Final Words..

Ok, lots of new stuff in 3.0, and 3.5 is already in the making ("The Protocol Release"), and to be honest I did discover a bug or two writing this (related to the browser and Deploy-As-War functionality), so be sure to get the latest nightly-build (at http://www.eviware.com/nightly-builds) and join in on the fun!

truly yours,

/Ole