OSB unit testing, part 1

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 !

Unit of test

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.

Scenario

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.

Request message:CurrencyConversionRequestMessage

Response message:

CurrencyConversionResponseMessage

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.

Creating the SoapUI TestSuite

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:

TestRequest

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:

MockResponse

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:

MockResponseConfig-2

And again, the proof of the pudding is … in the testing ! Run your soapUI test and verify it completes successfully:

Testcase-exec

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):

Testrequest-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):

Testresponse-assertions

Conclusion

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.

 

OVER DE AUTEUR

Technical Consultant (e-Business Suite & SOA) at Qualogy, specialized in integration and design/development of extensions to the Oracle e-Business Suite using Developer (Forms/Reports), Workflow, PL/SQL, Java (OAF) and SOA Suite 10g/11g. Certified by Oracle for SOA Suite 11g, BPM Suite 11g, Enterprise Linux 6 and Java (SCJP for Java 5) and by SOASchools.com as a SOA Architect & SOA Security Specialist. View my LinkedIn profile at http://nl.linkedin.com/in/milconuman/

3 Reacties op OSB unit testing, part 1

  1. Makker schreef:

    Hi Milco,

    Nice post. Did some posting on SoapUI myself and indeed I strive to create unit tests for my OSB services as well. Also I put a series of them (with different cases) in a testsuite that you can kick-off with one click, so in one glance you can see if everything still works after a change.

    The trick with the sleep is a nice one: I did not know that you could define a step at which the mock service should start. I struggled with this with testcases to test validations in asynchronous request-response setups: then the response is back too quickly. I solved it by starting a mockservice (not a test step) using a groovy script. But then you can’t provide assertions on the response.
    By the way, this kind of testing I also used to test BPM processes. Instead of using xpath-driven mock responses, in that situation I read the response messages from file using scripting.

    Since this is part 1, I take it you write about assertions in your next part?

    Regards,
    Makker

    • Milco Numan schreef:

      Hi Martien, thanks. Actually, I do not think assertions are that interesting to write about. I do think they’re absolutely essential, no unit test should be without assertion !
      In the second part on OSB unit testing, I dove into unit testing of services with an interaction with the database. In my current project, I had to do some manipulation of the database beforehand (e.g. setting up some reference data for use in the unit test), as well as assertions after execution (has the log record been written ?).
      Since we’re using the Free SoapUI, we don’t have all the fancy stuff regarding datasources/datasets that comes with the pro version and I had to think of an alternative approach.

      Kind regards,

      Milco

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

De volgende HTML-tags en -attributen zijn toegestaan: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Contact

Hebt u vragen of suggesties?

Mail info@qualogy.com!


De Bruyn Kopsstraat 9

2288EC Rijswijk (ZH)

The Netherlands

+31.(0)70 319 5000

  • Blog

  • Tags

  • @qualogy_news

  • @qresources

  • Reacties

  • Blijf in contact

    +31.(0)70 319 5000