In my current project, I inherited a lot of OSB components that have been developed by (former) team members, but they all lack unit tests. This is a situation I really dislike, since this makes it much harder to refactor or bug-fix the existing code base.
So, for all newly created components (and components I have to bug-fix) I strive to add unit tests. Of course, the unit tests will be created using my favourite testing tool: soapUI !
The unit test should be created for the service composition, which in OSB terms should be the proxy service combination with its business service. Now, since you do not want to rely on any other services, you should provide mock services for all services invoked from your Component-Under-Test.
In a previous article, I wrote about mocking your services in soapUI. While this approach would also be valid here, creating a mock service (and certainly deploying it on a separate WebServer) does violate one of the core principles of unit testing: to make your unit tests as self-contained as possible, i.e. not depending on any external components.
In this article, I will show you how to achieve this by simply providing a mock response inside your unit test.
The scenario I implement for testing is a simple currency converter; the external request consists of a from and a to currency, and an amount (in currency from). The service will perform an exchange rate lookup using the WebServiceX CurrencyConverter and return a response to the caller consisting of both the source and target currencies and amounts. For the purpose of unit testing, I will implement a mock response for the exchange rate lookup.
If you’re interested in the source code (OSB components and customization, soapUI project), you can find these at GitHub.
The customization file I use in unit testing overwrites the endpoint URI for the business service, so that no longer points to its WebServiceX endpoint but to the local endpoint http://localhost:17001/mockConversionRateService.
Although soapUI 5.0.0 has already been released, I used 4.6.4 as I could not get this example to work on 5.0.0 due to a suspected bug. So create a new project in soapUI, pull in both WSDLs (viz. the WSDL for your OSB proxy and the WSDL that is used by your business service — you will need to mock this one!) and create a test suite.
Start off by creating a SOAP Test Request:
Now add the mock response step and configure this to listen at port 17001 on localhost with path /mockCurrencyConverter This should match the endpoint in the OSB customization file. Now, provide a value for the time-out to prevent this step from never completing when no request is received (e.g. 1000 for a time-out of one second). Implement the message to provide an exchange rate:
The essential step is to make sure that the mock response is already listening before the actual request arrives. In order to achieve this, I added a “Delay” teststep (for 10 ms) as the first test step and I configured the Mock Response to use this “Delay” step as its start step:
And again, the proof of the pudding is … in the testing ! Run your soapUI test and verify it completes successfully:
After the first successful run, verify your results visually and add assertions to the request step (these assertions are executed against the response); assert that the service returns a SOAP Response, that it’s not a SOAP Fault, that it complies with the XSD and verify the payload (using one or more XPath or XQuery assertions):
Now, another advantage of using a mock response step instead of a mock service is that you can also verify your outbound request message. The request message you are sending by adding assertions to the mock response step. In this case, assert you’re sending out a proper SOAP request, schema compliant and verify the payload (using one or more XPath/XQuery assertions):
Using soapUI’s mock responses in your unit tests does not only create unit tests which are more self-contained (reducing dependencies), but it also allows you to verify outbound request messages!
P.S. Remember that the essential step is to make sure the answer (mocked response) is already prepared before the question (test request) has been asked by introducing a “Delay” step to configure SoapUI’s response to start before the request.
Hebt u vragen of suggesties?
De Bruyn Kopsstraat 9
2288EC Rijswijk (ZH)
+31.(0)70 319 5000