WSDL testing can be fun.  I’ve done this with SoapUI, and it’s more advanced successor Ready!API, which are both available from www.smartbear.com and www.soapui.org.  (In my opinion, test writing is vastly quicker using Ready!API due to the extra features, but that’s the tradeoff between free and paid-for software).

So, there are two ways you can write a suite of tests for a WSDL.  Using a few large tests, or using lots of small ones.  

The problem with writing large tests to cover multiple functional features, however, is that if one part of the functionality fails then a) you don’t know how much of the functionality has failed, and b) tracing / debugging it can be a nightmare.

My personal preference (and the most successful approach I have used) is to create many, small atomic tests, each focussing on a single feature in isolation.  

In this example, let’s say we’re working with a journey planner, which allows the user to query using the following attributes:

• journeyOrigin (where the journey goes from, which is a string value)
• journeyDestination (where the journey goes to, which is a string value)
• includeStopTaxiInfo (whether to include local taxi info for each stop)
  • True: Add taxi info to the response.
  • False: Do not add taxi info to the response.

The tests that I would include would be:

• Plan a journey (so that it can’t be planned).
• Plan a journey (so that it can be planned).
• Plan a journey (includeStopTaxiInfo = true).
• Plan a journey (includeStopTaxiInfo = false).

So with the includeStopTaxiInfo tests, we are using a known-good journey, and we are not interested in what the resulting journey is, but we are interested in whether the specific bit of info in the response is present or not.  This makes the tests much smaller – smaller to write, simpler to debug if anything is amiss.

There are benefits to this granularity.

• Test planning: If you know how many query attributes there are, then you can plan out the number of tests needed for each attribute option.
• Test writing: Writing a small test is easier and faster than writing massive all-encompassing tests.  Also, if you have a team, then the attributes can be split between team members.
• Test execution / reporting: When the tests are run, it is very easy to zoom in on the defects in the specific areas of the WSDL.
• Test maintenance: If the underlying functionality changes, then (although there are a large number of tests), the simple nature of each one helps with updating, plus the impact of the change can be scoped better as only the affected tests need to be updated.

With this approach, as you can see, it is much easier to get an accurate readout on the percentage of the WSDL functionality that is tested, and the percentage of the tests that run or fail.

This isn’t to say that large tests aren’t useful in some circumstances – but smaller, simpler, faster,  focussed tests make more sense from so many angles that this is the approach that I will be continuing with.