The new soapUI 3.0 beta has been out on our servers and at sourceforge for a couple of weeks now, the list of new features is as always extensive, and as always we owe most of it to our customers and users; all fantastic feedback, input, support and patience (a lot of that..) has propelled soapUI further towards SOA-testing Nirvana.

The New and Noteworthy document gives an overview of all new features in both soapUI and soapUI Pro, and instead of repeating its content, I'll write a number of entries over the coming weeks to show off some of the more prominent improvements. So lets dive right in and have a look at the extremely cool WADL generation and Schema Inference functionality!

What is it?

To make things simple; Schema Inference is the process of generating an XML Schema from a set of XML messages. Generating Schemas from XML is not a new thing, but soapUI puts some nice twists on this:

- as more XML messages are processed, the schema will continuously be improved; expanding min/maxOccurences, broadening datatypes, adding elements/attributes, etc.

- generated WADL files (which soapUI can do as well) for your REST service will naturally include grammar references to the generated Schemas (and export them as xsds if desired), useful for generating code and documentation

- since soapUI internally converts JSON to XML, a schema is generated for this XML as well, which can be used for validation, etc

What can you use it for?

As hinted above, the Schema Inference functionality is usefull in a number of situations:

- Creating Clients: Generation of Code from an inferred schema can be used to quickly create clients (using wadl2java) for consuming REST services

- Service Validation: validation of responses against an Inferred Schema ensures that a service behaves as initially "deducted".

- Documentation: Generation of documentation for REST services (which is totally against the rules.. )

- Test Coverage: Contract Coverage functionality in soapUI Pro will calculate the schema coverage in your functional tests against the generated schema, showing how much of the contract that has actually been utilized in your tests.

- Schema Validity; the generated schema can be compared to an existing schema (in some external tool), allowing you to find inconsistencies or unnecessary constructs.

As mentioned previously, JSON responses are also converted to XML for schema generation, and many of these scenarios can in soapUI be equally applied to JSON services as to XML services.

A quick walkthrough

Actually, the brains behind all this here at eviware, Dain Nilsson, has already written a very nice Getting Started tutorial, please follow his steps to generate a schema for the yahoo search service and I'll show you what you can do with it.

Alternatively, just import the below sample project into soapUI which gives you what he has done (why don't you try the remote project functionality; select the "Import Remote Project" option from the Workspace popup and specify the below URL):

http://www.eviware.com/blogs/oleblog/wp-content/uploads/2009/06/yahoodemo-soapui-project.xml

Code Generation

If you're a java developer that needs to integrate with a REST/HTTP service, the generated WADL+Schema can be run through the wadl2java toolkit from the folks at sun, which will generate appropriate client classes for you;

1. Download and install the latest WADL toolkit from wadl.dev.java.net (use the 1.1 snapshot)
2. Open the Global Preferences in soapUI and set the path of wadl2java appropriately:



3. Right-click the Yahoo Demo service in the soapUI Navigator and select eh WADL2Java option, this will bring up the following dialog:



4. Set the output-directory, package, etc as desired and press the generate button, which will start the wadl2java tool and show its output. If all is configured correctly you will get:

   
   

5. Ok, now import the generated classes and "off you go"..

Compared to standard parsing, this is much easier but you'll have to be sure that the generated Schema actually covers all the elements/attributes that you are going to access, otherwise you will have to refine the schema in soapUI (by making corresponding requests and extending the schema) and regenerate the code as described above.

Documentation Generation

The same schema can of course be used to generate a nice HTML documentation for your service; open the REST Interface / WADL Content tab and select the "Generate Documentation" button in its toolbar (3:rd from the left);

Generating the report runs an XSL stylesheet (taken from the sun wadl toolkit), which produces this nice result: wadl-report.html

Contract Coverage

Finally, lets look at how the generated schema can be used to calculate Contract Coverage for a hypothetic test of the Yahoo service, using the Contract Coverage functionality available in soapUI Pro. Start by adding the default request for the Yahoo service to a TestCase (second toolbar button from the left in the request editor), which will prompt you a number of times (just say yes) and open a corresponding REST TestRequest. Now open the generated TestCase and select the TestCase Coverage tab. Expanding all its nodes will give you the following:

Here you can see the different parameters and response representations, together with the number of elements available for coverage calculation for each in the bars to the right. Now

- Enable Coverage in the Toolbar
- Expand the Message Coverage inspector to the right
- Select the Response Representation to the left

This should end you up with:

All is red since we haven't actually run any tests yet, which of course gives us no coverage.

Now Run the TestCase by pressing the green arrow button in the toolbar, you will (hopefully) get the following result:

Here we can see that our default TestCase gave us a Contract Coverage of 83%, the entire message is green since all elements were present in the response, but the Fault representation is still red since we didn't get an error back and our TestCase thus didn't cover a negative result. Lets correct that while we are at it;

- Right-click on the REST Test Request in the TestCase and clone it with the highly imaginative new name "Method 1 - Request 2"
- Open that request and change the results parameter to a non-integer value; "asd"
- Submit the request to check that we are getting an error:

Now go back to the TestCase window and run it again, the results will be

Great! Now our TestCase covers both the positive and negative case. Our manager will be happy, and so am I because I didn't find any bugs writing this blog entry!

As you can see the last two rows in the Coverage tab above show the coverage for each of the requests by themselves, the first covering the positive case, the second the negative.

Now What?

Well, if you haven't downloaded soapUI 3.0 yet, don't hesitate and get it from sourceforge or go straight to the soapUI Pro beta download if you want to try the coverage functionality described above. And as always your feedback, insights, complaints, etc are all very welcome!

/Ole