A ProgrammableWeb plugin for SoapUI

The ProgrammableWeb is one of the major players in the API-directory space - wouldn't it be neat if you could browse their directory from inside SoapUI and import an API directly into your SoapUI project from there? Of course it would! Let's get right to it and create a simple plugin for SoapUI that lets you do just that.

Prerequisites

The API directory at programmableweb.com holds at the time of writing over 8000 APIs in its database, and although the majority is based on REST principles, over 1800 are actually still using SOAP. Since SoapUI can easily import the WSDL for a SOAP based API to allow you to do some ad-hoc explorations of the APIs operations, let's add a dialog to SoapUI that allows you to browse those SOAP-based APIs and import them into SoapUI. Of course SoapUI could import REST APIs as well if they had WADL or swagger definitions, but since the ProgrammableWeb directory doesn't expose links for these metadata formats, we'll have to stick to SOAP/WSDL for now.

My initial thought was to use the ProgrammableWeb Atom-based API for browsing and extracting all SOAP APIs in their directory, but unfortunately the API currently has no easy way to search for these APIs, I would basically have had to go through the entire directory, page by page, (remember, over 8000 APIs) and manually extract those of interest. Instead, I opted to do something I never thought I would do, "screen-scrape" the web interface of programmableweb.com - which is of course extremely fragile since any change to the underlying HTML will make the plugin useless, but on the other hand - the URL http://www.programmableweb.com/apis/directory/1?protocol=SOAP returns a nicely formatted list of all SOAP APIs in the directory - making things so much easier. As an added advantage, this approach does not require me (or anyone else using the plugin) to have a ProgrammableWeb API key, as we are just extracting data and not making modifications.

Enough talk - let's look at how this baby actually works:

In Action

Before we dive into the code, here comes a screenshot of the actual dialog invoked from a new "Add API from ProgrammableWeb" action on the project popup menu:

As you can see you select one of the API categories on top and the list under will contain all SOAP APIs in that category. The WSDL endpoint for the API is shown at the bottom - pressing OK will import the WSDL directly into SoapUI for further exploration:

I've posted a short video of this in action further down - let's just have a quick look at the code first.

The plugin code

The plug-in code is straight-forward - just like the soapui-swagger-plugin I published a couple of weeks ago. I'm not going to go through all lines of code (you can do that on GitHub, see below), just highlight a few things.

First, the project structure:

As you can see this is a maven project using both groovy and java. The main reason for using groovy was (once again) its superiority when it comes to parsing; the GPathResult returned by the HTTPBuilder for the ProgrammableWeb HTML pages is easily searched for the relevant information. For example the following code is used to load the SOAP API listing and extract all the APIs into a Map of categories to collections.

And the code for extracting the WSDL from an APIs detail page is equally simple:

The remaining code in the AddWsdlFromProgrammableWebAction class is mainly boilerplate code for setting up the form and initializing its data. Since the form is created only once SoapUI will have to be restarted for new APIs to show up in these lists.

A very short video

Ok, here comes a short video showing you how this actually works;

Nice - isn't it!?

Download and installation

Installing the plugin is straight-forward, download it from here and drop it in the soapui\bin\plugins folder (you will need at least SoapUI 4.5 - download from http://www.soapui.org). Also you will need to add the http-builder-0.6.jar and xml-resolver.jar files to the soapui\bin\ext folder - which are needed for loading and parsing the HTML pages. If your're on a Mac you can find or add these folders "inside" the application bundle, presumably at /Applications/SmartBear/soapUI-4.5.1.1-SNAPSHOT.app/Contents/Resources/app/bin.

SoapUI will load these during startup, as seen in the SoapUI log:

Wrapping up

That's it - check out the code at GitHub (https://github.com/olensmar/soapui-programmableweb-plugin) - and have fun with the plugin - and please don't hesitate to comment, suggest or complain :-)

Thanks for your time,

/Ole

Having fun with Cucumber, Groovy, Jacob, COM, TestComplete and Notepad

Finally I've had some more time to explore new stuff - and since BDD is steadily gaining in popularity I thought I'd try to see how one could achieve BDD with TestComplete - SmartBears indispensible tools for web and GUI testing. And even if you're not interested in TestComplete - please stay with me as I will use a bunch of other cool technologies on the way (as indicated by that seductive title).

The Cast

The main characters in this blog-post are:

• BDD (Behavioral Driven Development) is an extension of TDD where you define behaviours in an agreed-upon vocabulary and use these to drive your tests (greatly simplified) - read more about the whole idea at http://dannorth.net/introducing-bdd/
• Cucumber is one of the more popular BDD frameworks out there - here we will be using the java version (Cucumber-JVM) with its integrated support for the groovy language
• Jacob is an open-source library that makes it really easy to call COM objects on the .NET platfrom from Java - and specifically from groovy via the scriptom library.
• TestComplete is SmartBears premier tools for automated testing of Web and Desktop applications (for MS platforms)
• Notepad is the text editor that we all resort to once in a while

Of course several of these could be replaced with others; Cucumber with JBehave, TestComplete with any application that can be automated over COM (Word, Excel, Outlook, you name it) - and notepad with anything you might want to test with TestComplete; your website or a desktop application for example.

The feature definition

I started out by using cucumber and BDD for specifying a simple feature scenario - here it comes in cucumber lingo:

In cucumber (and most other BDD frameworks) you express your requirements in a Given/When/Then kind of syntax - reasonably legible by both business and developers. Agreeing on the vocabulary used in these files is probably one of hardest parts in BDD - and there is much written about it - in this case I've chosen an imperative approach which skips the nitty-gritty steps of the underlying actions (read more about Declarative vs Imperative at http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories.html)

The groovy cucumber code

The next step is to write the code that will be invoked to execute these "steps". Cucumber has a nice groovy integration which makes the code pretty straight forward - here it is:

As you can see there are handlers for Given, When and Then "events" in the feature file - these are "found" by cucumber using the specified regular expression syntax which is used to match the correspond Given/When/Then statements in the feature definition and extract arguments from them. The "World" closure at the top of the file should return an object that will be implicitly available in your other handlers, thus the calls to runRoutine and runRoutineEx further down are actually calls to the methods in the created TestCompleteWorld class.

Calling COM from Groovy

Calling into Windows applications can be done in a number of ways, in this case I wanted to access TestComplete via its COM Automation interface (read more about COM automation at wikipedia). This is where the jacob library comes into the picture - it makes it extremely easy to call into COM objects from Java - and thanks to the scriptom library for groovy calling COM from groovy is even easier. Given this, the groovy code here is more or less a proxy for calls made to TestCompletes COM interface, which just "proxies" the calls from cucumber to TestComplete.

To keep this plumbing outside the stepdefs file I have hidden it in the TestCompleteWorld class created in the closure at the top. Here comes the constructor that launches TestComplete and sets it up for handling our calls:

(see the entire class at GitHub)

If you are familiar with COM this is pretty straight-forward; the code creates or connects to an existing TestComplete object and does most of the further automation by calling methods in TestCompletes Integration object - which invokes the corresponding functionality in TestComplete.

The TestComplete scripts

All right - let's have a look at the TestComplete side of things; the project is very simple:

The project specifies notepad under the TestedApps node in the project, and contains two JScript units; "NotepadSteps"  (which you can see in the screenshot) contains the actual handlers called from cucumber, and "NotepadStepsTest" which I used to test the handlers during development. The handlers themselves are pretty simple; they automate notepad (ie run it and invoke it's actions) and write some logging information to the TestComplete Log. Thanks to TestCompletes recording functionality it is easy to create handlers that invoke UI actions - as the recording can be converted to a script that you can refine as desired (which is what I did for the "I_load_the_file" method).

I have set the names of the handlers ("notepad_is_running", "I_load_the_file", etc) to be the same as the corresponding handlers in our groovy Stepdefs above - but this is just a convention, I could have named them anything valid.

The Intellij Project

The corresponding IntelliJ project for the above looks as follows:

Core components (as already described above) are:

• NotepadStepdefs.groovy - the groovy handlers shown above 
• TestCompleteWorld - the groovy class shown above
• notepad.feature - the feature file shown above

Additional resources are:

• a custom CukeRunner to run JUnit tests with Cucumber (an empty class with some annotations)
• text files in the src/test/resources/data folder used in the tests themselves
• the TestComplete project is in the src/test/resource/testcomplete folder
• the maven pom.xml (although the tests don't run with maven yet - to be fixed)
• the jacob dlls copied to the root folder of the project (so they can be found during execution). Jacob will choose the one corresponding to your architecture automatically

How it all fits together

Since a picture says more than many words - so here comes a diagram trying to give you an understanding of how all these components fit together:

(the 3 components in green are those that I had to code myself)

Verbally this translates to; when running my tests I use JUnit which uses a custom CukeRunner to invoke Cucumber, which reads the feature file and calls the corresponding handlers in the groovy Stepdefs. These in turn use the Jacob library to launch and automate TestComplete, which in turn automates Notepad via JScript handlers. Piece of cake.

Action!

Instead of showing you a bunch of screenshots of this running I've created a short video - please bare with the quality and enjoy that this actually works :-)

How would one use this?

Here at SmartBear we will be evaluating this framework for automating basic GUI tests of both SoapUI and LoadUI. Given there are three main artifacts required here (the feature files, the stepdefs and the TestComplete handlers) it makes for a pretty good fit for how we work; features are defined together with the product owner and the stepdefs and TestComplete scripts are created by devs and testers in our team - the clear separation between these could make for a nice workflow (but we'll see about that - and I promise to report back even if it fails).

Next Steps?

For us we will be looking at how to get this running from Jenkins (which will pose some challenges in regard to launching windows applications), and we will of course expand our feature vocabulary and corresponding scripts in line with our requirements.

For you? The sky is the limit!

The above code is on GitHub at https://github.com/olensmar/cucumber2testcomplete. - please don't hesitate to comment, complain, suggest or fork!

Thanks for your time,

/Ole

P.S. If anyone could suggest an easy way to get syntax-colored code into a blogger blog-post I would be very grateful, inserting screen-shots of editors seems kind-of flaky...

Using mongoDB with soapUI

Using mongoDB with soapUI turns out to be incredible easy - mostly thanks to the gmongo project which provides a groovy layer on top of the mongo java driver. Let's have a quick look at some example on how this works.

Getting Started

Start by downloading the latest gmongo and mongo-java-driver versions and putting them in the soapUI\bin\ext folder - restart soapUI and you will see them getting picked up by soapUI as it starts (in the soapui log tab at the bottom of the main window):

If you don't already have mongoDB installed - download and install it on your machine and make sure it is running.

Writing Data to a mongoDB Collection

Let's start by writing some data to a mongoDB collection. I'm going to take the result from a call to the Flickr cameras API call which gives a list of all camera makers used by flickr users, and write each of these camera brands to my local database. The REST call to flickr is straight-forward:

Since Flickr requires an API Key I've put that in a project property so I can easily reuse it in all my other Flickr calls - the rest is straight forward for the flickr.cameras.getBrands call - you can see the response from Flickr to the right in the window above.

To write this to my mongoDB using a combination of a DataSource and DataSink TestStep - the DataSource uses the XML DataSource configuration to loop the brand elements in the response:

How this type of DataSource works is described in more detail at http://blog.smartbear.com/software-quality/bid/170520/How-to-Use-XML-DataSources-for-Response-Processing-in-soapUI.

Instead let's focus on the DataSink:

As you can see I've set up a Groovy DataSink with an extremely simple script to write the current rows data to a  mongo collection - this is called every time the DataSink TestStep is executed;

• The connection to the database is set up the first time the DataSink is called and saved in the context
• The current rows properties are written to the cameras collection; since properties is a Map it can be "streamed" directly into the collection using the << notation

That's it - the entire structure of my TestCase is as follows:

We have:

1. Our REST Request that gets the list of camera brands
2. Our DataSource that reads each row from the flickr response
3. Our DataSink that writes each row to mongoDB
4. A DataSourceLoop Step that ensures that we read (and write) each row

Running this unfortunately doesn't give us too much information. Lets' add another TestCase that reads this data from our cameras collection and uses it to make requests to flickr.

Reading from a mongoDB Database

The DataSource will be of type Groovy and looks as follows:

The script initializes its connection to mongoDB upon first execution and also creates a cursor for the cameras collection. Next it checks if there is another row and  in that case copies the row values to the DataSource properties. If there is no more data the result object is left empty - which is interpreted by soapUI that the DataSource has been exhausted.

We're going to use this data in a group-search request to Flickr - just to make sure that there are at least 3 Groups for each brand of camera. The request is straight-forward;

As you can see the ApiKey is being used here again - and the name property of the DataSource is being used in the text search field. When we run this we get something like:

As you can see we have a DataSource Loop at the end of the TestCase that will jump back to the Group Search Request for each row found in the DataSource. Pretty Neat - huh?

Making it easier

Ok, I admit that the above example was a bit overdone - let's just have a quick look at a groovy script step that would read all the data from the cameras collection and log it to the log:

import com.gmongo.GMongo

def gmongo = new GMongo()
def cursor = gmongo.getDB( "soapui" ).cameras.find()

while( cursor.hasNext() )
{ 
    def camera = cursor.next()
     log.info "Found camera with $camera.id names $camera.name" 
}

Dead simple - right?

Future Ideas

Some more ideas of what you could do with mongoDB in soapUI

• Create a TestRunListener that logs all TestStepResult objects to a mongoDB database - so you can track test execution results - replay tests - etc.
• Create a custom mongoDB TestStep that reads data and exposes it as properties (see http://blog.smartbear.com/software-quality/bid/170458/Creating-your-own-TestSteps-in-soapUI for an example)
• etc..

so much fun - so little time :-)

Conclusion - wrapping up

Thanks to the gmongo library and the many scripting possilibities in soapUI - accessing a mongoDB database from soapUI is pretty straigh-forward.

You can download the gmongo distribution from https://github.com/mongodb/mongo-java-driver/downloads,  the java-mongo driver is available at https://github.com/mongodb/mongo-java-driver/downloads.

I suggest you dig into the gmongo documentation at https://github.com/poiati/gmongo - it has a lot of cool features for making mongo java programming much easier.

And as I'm sure you know - soapUI and soapUI Pro can be downloaded form http://www.soapui.org

Thanks for your time!

/Ole

A swagger plugin for soapUI – with a little help from Groovy

Swagger is a simple vocabulary for providing metadata for an HTTP API (ie REST) for which it can be used to generate code, documentation, tests, etc. In this article I'll show you how to create a soapUI plugin in java and groovy that allows you to import JSON-based swagger definitions into soapUI for immediate ad-hoc, functional, performance and security testing of these described APIs.

Background

I first heard about swagger in one of Kin Lane's presentations at apidays.io earlier this year. Basically it’s a metadata vocabulary for describing HTTP/REST APIs; which operations there are, what path and parameters they have, which methods to use, dataypes (using JSON Schema!) etc. To be honest I was a bit surprised that someone had put quite an effort into something that seems to solve a problem that has already been solved (ie with WADL/XML Schema). But on the other hand, re-inventing the wheel often gives new insights and perspectives on its target domain and in this specific case the heavy use of JSON makes swagger easily accessible from most popular scripting platforms (note: swagger works swell with XML too). Also, the folks at wordnik have made a fantastic effort by providing an ecosystem (available at github) containing tools and libraries to make your adoption of swagger as easy as possible.

Since soapUI is specifically geared at reading API definitions (WSDL and WADL as for now) for generating API tests, adding support for swagger seemed like a natural step forward – and a good way to learn a little more about swagger itself and groovy as soapUI-plugin language.

The plugin project

I initially opted for creating the plugin entirely in groovy, primarily because JSON processing in Java is such a pain – unfortunately though I had to make some exceptions on my way forward, as you will see below. Using the gmaven plugin and related groovy project archetypes it was straight-forward to create an empty groovy project, now all I had to do was:

• Create the action class to import a swagger definition
• Add a META-INF/actions.xml file which soapUI needs to map the action into the correct menu
• Make some adjustments to the pom.xml (dependencies and resource inclusions)
• Write some basic junit tests to make sure things are working

The entire project in eclipse looks as follows:

(You can download the plugin source and jar file from the bottom of this article)

Let’s walk through these one by one.

The AddSwaggerAction class and soapui-actions.xml file

The AddSwaggerAction class is what is triggered by the associated menu item (the reason it is implemented in Java and not in Groovy will be evident a bit further down). It extends AbstractSoapUIAction and is parameterized with the type of soapUI object it will be associated with; WsdlProject (ie the project node in soapUI).

public class AddSwaggerAction extends AbstractSoapUIAction
{
 private XFormDialog dialog;

 public AddSwaggerAction()
 {
  super( "Add Swagger", "Imports a swagger definition" );
 }

The constructor calls the super-class with the actions name and description – the XFormDialog is from soapUIs internal dialog-framework (more to come on that).
The perform method is called when the corresponding action is triggered via the menu:

public void perform( WsdlProject project, Object param )
{
 // initialize form
 if( dialog == null )
 {
  dialog = ADialogBuilder.buildDialog( Form.class );
 }
 else
 {
  dialog.setValue( Form.SWAGGERURL, "" );
 }

 while( dialog.show() )
 {
  try
  {
   // get the specified URL
   String url = dialog.getValue( Form.SWAGGERURL ).trim();
   if( StringUtils.hasContent( url ) )
   {
    // expand any property-expansions
    String expUrl = PathUtils.expandPath( url, project );

    // if this is a file - convert it to a file URL
    if( new File( expUrl ).exists() )
     expUrl = new File( expUrl ).toURI().toURL().toString();

    // create the importer and import!
    SwaggerImporter importer = new SwaggerImporter( project );
    RestService[] services = importer.importSwagger( expUrl );

    // select the first imported REST Service (since a swagger definition can 
    // define multiple APIs
    if( services != null && services.length > 0 )
     UISupport.select( services[0] );

    break;
   }
  }
  catch( Exception ex )
  {
   UISupport.showErrorMessage( ex );
  }
 }
}

@AForm( name = "Add Swagger Definition", description = "Creates a Rest Service from the specified Swagger definition" )
public interface Form
{
 @AField( description = "Location or URL of swagger definition", type = AFieldType.FILE )
 public final static String SWAGGERURL = "Swagger Definition";
}

The key to understanding this method is the annotated Form interface at the end; it defines a form containing one field – the URL or filename of the swagger definition. As you can see the type of the field is set to AFieldType.FILE – which ultimately was the reason for this class being in Java - I couldn’t get the groovy compiler to work with this construct where the annotation attribute uses an enumeration; the class generated by the groovy pre-compiler failed to compile for some reason (after banging my head against that wall for 2hours I gave up and went back to Java…). If you have a solution to this please let me know :-)

The Form interface is used to generate the dialog class (by the ADialogBuilder) which is shown when the action is triggered. The specified URL is checked for a file-name – and the actual import is delegated to the SwaggerImporter class (see below).

The actions.xml file is equally simple:

<?xml version="1.0" encoding="UTF-8"?>
<tns:soapui-actions xmlns:tns="http://eviware.com/soapui/config">

<tns:action id="AddSwaggerAction" actionClass="com.smartbear.restplugin.AddSwaggerAction"/>

<tns:actionGroup id="EnabledWsdlProjectActions">
   <tns:actionMapping actionId="AddSwaggerAction" position="AFTER" positionRef="AddWadlAction"/>
</tns:actionGroup>

</tns:soapui-actions>

The AddSwaggerAction action is defined for our AddSwaggerAction class and mapped to the EnabledWsdlProjectActions group (which is used to build the right-click menu for an enabled Project) – it is positioned after the “Add WADL” action (see below for a screenshot).

The SwaggerImporter

This is the “powerhouse” of the plugin – it reads the specified swagger definition and creates the corresponding REST Service(s) in the specified soapUI Project. The main reason for using groovy was the JsonSlurper introduced in Groovy 1.8 which makes JSON parsing and processing so much easier. The “heart” of this class is the importApiDeclarations method:

public RestService importApiDeclarations( def url ) {

 // load the specified document
 def doc = loadJsonDoc( url )
    
 // create the RestService
 RestService restService = createRestService( doc.basePath, url )  

 // loop apis in document
 doc.apis.each {
  it

  // add a resource for this api
  RestResource resource = restService.addNewResource( it.path, it.path )
  resource.description = it.description

  // check for format template parameter - add at resource level so all methods will inherit
  if( it.path.contains( "{format}" )) {
   RestParameter p = resource.params.addProperty( "format" )
   p.setStyle( ParameterStyle.TEMPLATE )
   p.required = true
   p.options = {"json"}
   p.defaultValue = "json"
  }

  // loop all operations - import as methods
  it.operations.each {
   it

   RestMethod method = resource.addNewMethod( it.nickname )
   method.method = RequestMethod.valueOf( it.httpMethod )
   method.description = it.description

   // loop parameters and add accordingly
   it.parameters.each {
    it

    // ignore body parameters
    if( it.paramType != "body" ) {

     RestParameter p = method.params.addProperty( it.name )
     def paramType = it.paramType.toUpperCase()
     if( paramType == "PATH" )
        paramType = "TEMPLATE"

     p.style = ParameterStyle.valueOf( paramType )
     p.required = it.required
    }
   }

   // add a default request for the generated method
   method.addNewRequest( "Request 1" )
  }
 }

 return restService
}

As you can see it basically traverses the API definitions in the specified JSON document and creates the corresponding soapUI objects – fortunately the mapping between swagger and WADL (which is used to model the REST object model in soapUI) is straight-forward;

• An API in a swagger resource listing maps to a RestService
• APIs in a swagger API Declaration map to RestResource
• Operations in a swagger API map to RestMethod
• Parameters in a swagger operation map to RestParameter

The Unit Tests

A simple GroovyTestCase with two tests to validate the base functionality of the SwaggerImporter:

void testImportResourceListing() {
 def project = new WsdlProject();

 SwaggerImporter importer = new SwaggerImporter( project )

 RestService [] result = importer.importSwagger( "http://petstore.swagger.wordnik.com/api/api-docs.json" )

 assertEquals( 2, result.length )

 RestService service = result[0]
 assertEquals( "http://petstore.swagger.wordnik.com", service.endpoints[0])
 assertEquals( "/api", service.basePath, )
 assertEquals( 6, service.resourceList.size())

 service = result[1]
 assertEquals( "http://petstore.swagger.wordnik.com", service.endpoints[0])
 assertEquals( "/api", service.basePath, )
 assertEquals( 3, service.resourceList.size())
}

void testImportApi() {
 def project = new WsdlProject();
 SwaggerImporter importer = new SwaggerImporter( project )

 RestService [] result = importer.importSwagger( "http://petstore.swagger.wordnik.com/api/api-docs.json/user" )

 assertEquals( 1, result.length )

 RestService service = result[0]
 assertEquals( "http://petstore.swagger.wordnik.com", service.endpoints[0])
 assertEquals( "/api", service.basePath, )
 assertEquals( 6, service.resourceList.size())
}

Both tests create an empty soapUI Project and import a swagger definition into it; the first test calls the sample swagger resource listing provided on the swagger website and validates that it imports two RestService objects, the second calls one of the API Declaration directly and does corresponding validations (since the resource listing is optional a user might provide this directly).

Building and deploying

Building with maven is obviously easy – the maven pom.xml adds a bunch of soapUI dependencies (this will be much easier when the soapUI codebase itself makes the move to maven 3 in the near future) and a resource declaration, apart from that it’s a standard groovy/maven pom. Running mvn clean install churns a short while and creates the desired plugin jar in the target folder:

The plugin jar contains the compiled classes and resources (open it in a zip-file utility to see for yourself). All we need to do now is place this jar in a “plugins” folder under our soapUI\bin folder and start soapUI – the soapUI log tab at the bottom of the main soapUI window shows that the plugin gets loaded ok:

Swagger Action!

Now that soapUI is running and the plugin is installed let’s start by creating an empty project and right clicking the project node:

Select the “Add Swagger” menu option to bring up the dialog we created in the Action class:

Start by specifying the sample api-docs.json definition that we used in the unit-test (at http://petstore.swagger.wordnik.com/api/api-docs.json) – press OK and soapUI will work a little while resulting in:

Awesomely cool – now you can invoke the APIs methods, create tests, etc.. (head over to soapui.org read more about how to get started with REST Testing in soapUI).  

Since this isn’t a “real” service you might be tempted to try one of those instead; Singly creates swagger definitions for its APIs, if you head over to their API Explorer at https://singly.com/explore you’ll eventually get something like:

Press the Raw link highlighted in the image above to get to the /profile swagger definition:

Now paste the URL of the definition into the “Add Swagger” dialog in your soapUI Project and you’ll get a corresponding REST Service created with a sample request that you can submit with the access_token given in the Singly API Explorer:

WADL for imported swaggers

Since soapUI internally models REST services in alignment with the WADL specification, you can actually get a WADL for the imported swagger definition, just double-click the REST Service node and go to the WADL Content tab:

This WADL can be exported, used for code generation, etc. What fun!

Final thoughts – next steps

As noted above there are some things missing in regard to the swagger import;

• No support for models and datatypes (swagger uses JSON Schema to define these)
• No support for swagger definitions in XML – only JSON for now
• Very limited error-handling
• The unit tests are dependent on the online swagger examples – they will fail if these change/move/etc.

So if you feel the urge to improve the importer or plugin – please do, and please contribute your changes back to me so I can put them in this distributable!

And as mentioned earlier – if you have suggestions on how to come around my gripes with the groovy compiler and enumerations for annotations attributes – let me know!

Resources and downloads

If you want to know more about swagger just head over to  http://swagger.wordnik.com/, the importer was created for the specifications at https://github.com/wordnik/swagger-core/wiki/Resource-Listing and https://github.com/wordnik/swagger-core/wiki/API-Declaration.

If you want to know more about how to create soapUI extensions/plugins head over to http://www.soapui.org/Developers-Corner/extending-soapui.html on soapUI.org or read a previous post on the subject at http://blog.smartbear.com/software-quality/bid/170458/Creating-your-own-TestSteps-in-soapUI.

If you don’t have soapUI installed (shame on you!) you can download it from www.soapui.org.

You can download the source for the entire above project here and the built jar here – just put this in the soapui\bin\plugins folder as shown above to start using it (it requires soapUI 4.5.X or later)!The project is also on github: https://github.com/olensmar/soapui-swagger-plugin

If you have any questions or comments please don’t hesitate to ask below - thanks for your time!

/Ole