I'm trying to figure out the best way to write unit tests for Spring's WebService Template classes. What I'm trying to do is check to make sure that I wired these classes up correctly for each request/response type that my client is producing. I also want to make sure that if an exception is returned the exception is handled correctly.
I guess what I'm trying to do is figure out a way to make the actual send/receive calls.
Any suggestions?
I'm going to be tacky and answer my own question.
After a little further research I found that Spring WS 2.0 has a new client testing framework that does exactly what I was hoping to do (from http://blog.springsource.com/2011/01/11/spring-web-services-2-0-released/):
The core class for doing client-side integration testing is the MockWebServiceServer. The underlying idea is that the web service template connects to this mock server, sends it request message, which the mock server then verifies against the registered expectations. If the expectations are met, the mock server then prepares a response message, which is send back to the template.
The typical scenario of testing client-side code consists of:
- Creating a MockWebServiceServer.
- Setting up expectation(s) about the request message.
- Creating an appropriate response message
- Using the WebServiceTemplate as normal, either directly of through client code.
- Call MockWebServiceServer.verify() to make sure that all expectations have been met.
Now unfortunately my project still uses spring-ws 1.5.9. I'm going to try and upgrade just the client to 2.0 and see if anything breaks. If that goes well I might try switching over the server side soon.
Strictly speaking, unit tests should not use WebServiceTemplate at all. Your code should talk to the WebServiceOperations interface, and should be unit tested using e.g. mock objects. This makes no network calls, it only tests the java that you write.
What you're describing is better referred to as an integration test, where you test that your wiring is done properly, possibly including a call to the real web service.
In this case, the integration test complements the unit test. My advice - write both.
What you've describe isn't really a "unit test" anymore, as you are testing more than just the single unit of your class that uses WebServiceTemplate in isolation. A good unit test of this class would probably involve mocking the WebServiceTemplate class so that you can test how your class behaves when the WST returns different types of responses, exceptions, etc.
For a test that verifies how your class behaves at runtime with wired-up collaborators (and a Spring context), you should check out Spring's TestContext Framework. This allows you to annotate your test classes with things like @ContextConfiguration({"path/to/spring/xml"}) to have Spring instantiate an ApplicationContext prior to running your test, and inject any @Autowired properties into your test class.
A final note: testing your webservice-using classes against a live web service is typically a bad practice, as this introduces outside dependencies on your tests - is the service up and running? What server is it on? What version is it at? etc. You may not want to run these tests as a part of your normal unit test suite.
soapUI is a good option for testing your exposed WS. You can hand craft the requests for ad-hoc testing or automate the predefined tests in a variety of ways.
