SOA Suite Components, OSB Proxy Services, and transformations are software artifacts you might want to test in isolation. But this is a hard task because you don’t have built-in support for “real” unit tests. SOA Suite allows unit testing whole SCA composites. While this is prohibitively slow for Test Driven Development (you need to deploy your composite to a server to test it) and doesn’t support certain kinds of assertions, it is still better than nothing. But if a composite consists of many internal components like a Rules Component, a Mediator and a BPEL component, you have no chance of testing them in isolation.
You can also use soapUI to test your composites or proxy services. This can be automated using the soapUI Maven plugin (and I strongly encourage everybody to automate their tests). The key to testing in isolation is to replace all external dependencies with mock services with a specific behavior. If you want to test a SOA Suite composite, make the endpoint URLs of your referenced services point to mock services created with soapUI. You can change these URLs using configuration plans. In the soapUI test suite, make sure to start the right mock services before the respective test using a script.
If you want to test an OSB proxy service, you will have problems replacing some dependencies with mocks. This is because OSB “hardwires” Proxy Services together if the transport protocol is “local”.” You will need to manually create mock proxy services and change the URLs using customization files because you cannot change the transport protocol this way. For the same reason, if you want to test a service that has a different transport protocol than SOAP, you need to create a SOAP wrapper proxy so soapUI can access your testee. Unfortunately, soapUI doesn’t support assertions (verifications) on service mocks. So your test cannot assure that calling a service with certain input results in some backend service invocations. You can only specify assertions about the response, so you are out of luck when the service has a one-way interface. If you have complex XQuery transformation in your OSB project, you should unit test them. James Nash’s XQAbstractTest provides a good basis. You might choose a similar approach to test XSLT transformations, taking care to use the same XSLT implementation your target application server uses. (Regarding manually “testing” OSB artifacts (which I rather call “trying out” than “testing”), check out the OSB Test Console.)
Unfortunately, the OSB testing options haven’t been improved in almost five years. My wish list for future releases of Oracle SOA products:
- unit testing in OSB just like in SOA Suite
- fine-grained testing of components like transformations or rules components
- “negative” assertions on references services (“assert this service was NOT called”)
- fast unit test that can be executed without redeployment
- easy replacements of services with mocks