Testing Approach with OSB
I have been having a thought about what’s the best way forward with automating unit tests with OSB
First of all there are 2 things here…
One is Unit testing and the Second bit is automating them…
UNIT TESTING with OSB
A customer of mine was very keen on unit testing and automation and this is what I explained to them. There isn’t that much of an issue in adding unit tests to all services just that it means we do some additional work mocking services.
For SOAP Services it’s simply a case of writing SOAPUI web services test cases.
However since most of the integrations at the customer weren’t synchronous SOAP Services we will have to write test cases for JMS messages. Again this can be done via SOAPUI or we can also use something like citrus.
“Citrus is an integration testing framework written in Java that tests your software application to fit into your customer’s environment. The tool simulates surrounding systems across various transports (e.g. Http, JMS, TCP/IP, SOAP …) in order to perform automatic end-to-end use case testing.“
For JMS based Messaging services again we can have SOAPUI test cases as we did for the earlier phases of the project.
However the bit where we might struggle or may be have to tweak things a bit is when it comes to proxy chaining which isn’t SOAP or JMS… eg. Local protocol provided by OSB i.e. proxies that can’t be executed from the outside world…
SO for these we have the following options
1. Do nothing i.e. don’t unit test them just test with other services… which may not be that bad as they are like internal services.
2. Change the protocol in Dev environments allowing them to be tested individually however that might also come with other complications like there is a difference in how transactions work in local proxies etc… also the headers are different in SOAP over HTTP from JMS and the same for local.. so further analysis really needs to go into this but most likely we will have to break these down on a case by case basis and would end up with 3-4 different scenarios based on the blueprints.
3. Also looking at some blogs people are talking about adding SOAP based wrappers for such services. Which we can consider, just that I am not a big fan of adding code that isn’t really part of your project but with careful governance we can take this approach…
Another aspect you want to consider is how we test transformations
Eclipse lets you unit test them from the IDE and can also be tested from the OSB console.
I haven’t tested it using any tool before but can see people have written java code to automate this. http://osbutils.googlecode.com/svn/tags/XQTestFramework-v0.2/src/com/oracle/uk/ocs/osb/xqtest/XQAbstractTest.java might be worth testing it.
In addition another approach commonly used and documented by some fellow bloggers is that we can wrap Transformations and simple services without much overhead which allows them to be easily tested along with other services using SOAPUI for example.
So all in all we can have unit tests for OSB just that we need to identify all the scenarios i.e. soap calls, jms services, adapters, sync, XQuery transforms one way services etc… Also Queues and we should be able to unit test them…
There is a very useful post on Eric’s site regarding how to use Citrus framework which can plug with maven to provide automation of unit tests.
Part 2 AUTOMATING Unit Tests
If we want to initiate the entire unit tests and plug them with the Continuous integration
I think the biggest challenge is that normally unless you have a dedicated environment which only contains the mocks you would struggle to do that. In a normal integration environment we will need to first either automate creation of a session executing a Customization file which switches the endpoints to mocks and then executes the requests (all this is doable using maven and automation scripts – just not desirable)….. The good thing is with OSB you can undo a session so may be post execution the changes to endpoints in rolled back.
Preferred solution: would be to have a dedicated Unit test environment with all the mocks running on this environment, which can be used with CI. As soon a developer checks the code in the CI kicks in and checks the code out, performs the build, executes all the test cases and provide you the report about the test coverage. This can work with Bamboo as it has worked with Continuum and some other tools which I have tried in the past, I might be looking to hook this will Bamboo in the coming few days for one of our customers.
Test coverage Reports using SOAP UI
Test Coverage using Citrus
Other thing that just came to mind was maybe we can be using dynamic routing to switch between mock or real endpoints based on the input message but in that case the mock business services will have to live on the server as well…again you wont want these to progress through the environments so you will have to have a strong governance model around how to ignore certain files from deployments…. Or may be how to ignore all files sitting in the Unit test folder of the project…. Again more thought needs to go into each of these options…
Continuous Integration with OSB – http://redstack.wordpress.com/2013/05/02/building-osb-projects-with-maven-and-removing-the-eclipse-dependency/
These are the just the various options I have considered so far for the Testing Approach with OSB and how it plugs into CI… Further analysis may be needed for some of these to ensure they are the best possible solution for your organisation.
I would be interested to know what your views are on some of these?