Just got this question from a blog reader:
I am evaluating whether to use FitNesse with FitSharp for acceptance testing some web services.
In reading your book and searching online, I could not find a template or recommended approach to doing this. The following is a working idea on the approach. I would like to hear your feedback if there is a better means of doing this!
Template for writing web service acceptance tests:
- Generate proxy class using the SVCUTIL / WSDL tools in Visual Studio .NET
- Wrap the proxy in a helper class that exposes properties for the requests/responses along with setting up the endpoint. This class also includes an Execute() method.
- Compose a fixture class containing an instance of the helper class
- From FitNesse, initialize the setup of a fixture object with endpoint data and instance variables for web service communication.
- Execute()
- Check data in assertions
This very much depends on who the stakeholders are for the tests – who is concerned about them and who is involved in writing them.
FitNesse magic works best on automating shared expectations about what the software should do before you start writing code – examples that you can agree on with your business customers and analysts, because you can automate these examples and still keep them in a human readable form.
You can still get some benefits using fitnesse in a legacy environment if you decide to write tests for existing software but need to have them in a form that is easily readable by business analysts. But in this case just wrapping a web service with a technical autogenerated fixture won’t do the trick – try to create a table format that makes sense for the business instead of basing it on a technical wsdl.
If you don’t need this, and if the only stakeholders for these tests are developers, then you won’t get any benefits from FitNesse over MBUnit and it will give you higher maintenance costs.
If you are testing web services after the fact – after they were written – you will probably get much better return on your investment in test in just using a technical test tool such as NUnit or MBunit.
Related post: How to implement loops in FitNesse test fixtures
|
|
Two weeks ago I blogged about the needle eye pattern, our approach to testing remote services over RMI on a Java based application.
http://blog.shino.de/2010/04/24/the-needle-eye-pattern/
The pattern is more on the implementation side of the application. Above the low-level classes we create, we build a business abstraction layer, so that it’s easy to write high-level tests. Using the needle eye pattern we can get rid of the remote server dependency in our fixture code, thereby reaching a great code coverage for the Fixture code. On top of that we have the fixture code making use of the service executor, in order to translate between the business language as expressed in the FitNesse tables and the low-level services provided by our system under test. This is our first step to get legacy code with awkward dependencies under test.