Oracle Service Bus and Unit Testing
By MarkSmith on Aug 01, 2008
Every decent programmer knows the importance of unit testing. One of my colleagues always says “Your code is only as good as your tests”. Those writing the code can comprehend the importance of this statement. The challenge is to convince those approving the project plans that this stuff is important. Testing frameworks for java code, like JUnit, have been available for years. But what about testing services defined in Oracle Service Bus. (Previously ALSB) If you Google ESB and Automated Unit Tests, I don’t think you are going to find much.
Some of my colleagues have been exploring the options when it comes to testing services defined in OSB. Some of the results have been so impressive; they are worth mentioning in my blog. But before I go into the new stuff, let’s have a look at the Service Bus testing basics.
Starting with a simple message flow through OSB:
1. Proxy Service ‘A’ receives a request. This proxy is just designed to receive the request and then pass it onto a common local proxy that does all the work.
2. Proxy Service ‘B’ does some data translation and transformation on the message. This contains all the business logic and therefore should be unit tested.
3. Proxy Service ‘B’ then routes the message to some external endpoint using Business Service ‘X’.
This message flow is demonstrated in the diagram below:
One of the simplest ways to isolate and test Proxy Service ‘B’ is to use some of the existing service bus components. We can simulate the request coming into Proxy Service ‘A’ by creating our own proxy driver. This proxy can formulate the request message that Proxy Service ‘B’ expects, call Proxy Service ‘B’ and then examine the results returned if a response is required. We can also simulate the end service by creating our own proxy stub that Proxy Service ‘B’ can call. This proxy stub can validate the request it receives and can return a response if required.
The use of a Driver and Stub is demonstrated by the diagram below:
This approach is fine as an interim step during development, but has limitations and draw backs. The problems with this approach are:
1. You have to create extra components (proxy drivers and stubs) that have to be stored with the actual code. You probably will not want these deployed to you production environment with the main code, so they will need to be removed or omitted during the deployment process.
2. Manual intervention was required. The services under test have to be modified to point to the respective stub rather than the actual service. In the diagram above, Proxy Service ‘B’ must be modified to use the proxy stub rather than Business Service ‘X’. One of the first rules of unit testing is not to modify what you are trying to test.
3. This testing is course grained. There are limits to what you could actually test.
4. Comparing actual with expected results is cumbersome and is usually done manually.
5. This approach does not lend itself to being automated.