Test Driven SOA

Work in Progress, 9/9/11

There's not much material out there generally to help get people up and running with SOA Suite, relatively speaking. There is next to nothing on testing appart from a smattering of Oracle links (here for example). One notable exception is Bob Webster's excellent pages on Business Rules Testing, which really got me thinking.

The scenario is:

***SOA 11g PICTURE***

The componentised nature of SOA Suite should facilitate a TDD approach. With this in mind, lets look at a potential strategy in which to frame the work.

General Principles

This strategy is governed by the following principles:

  • Development shall be test driven where possible, from the classes and unit tests to usecases and acceptance tests.
  • As much testing as possible shall be automated.
  • Seek economies of scope in your test coverage: use easy to maintain tests as much as possible.

Types ofTest

We'll follow a typical v-modeltest hierarchy, starting at the 'bottom' and working out to the full systemtest scope.

  • UnitTest: These depend on the component at hand. For some technologies (e.g. Human Tasks) its not possible. For others, notably 11g Business Rules designer, the unittest capability is built in. Depending on the complexity of the component, we may not have many of these.
  • ComponentTest: These are tests run against our components' exposed webservices. Here's my example of a primative java.main() type harness for testing a business rules service, using the SOA 11g sdk to get at the decision service endpoints programmatically). The approach works against any component with an exposed soap service.
  • Cold SystemTest: The point oftest is the where the main process enters, in our example the exposed webservice for the first mediator. We'll use the sametest harnesss (junit -> SOA 11g web service references)
  • Hot SystemTest: These tests we'll run against the live WebLogic server using SoapUI's testrunner. Its quick, it integrates with Jeeves (formally known as hudson), and it works. Thistest harness will need to talk whatever protocol the live system uses. My example runs over MQ.
  • Eyeball Tests: At the end of the day there's no substitute for firing up the (WebLogic) server and running the application. Problem with these tests is you can't run them 100 times a day, but they work well for ad-hoc testing (e.g. SID/Standard Idiot Testing) or formal end-of-phase witnessed acceptance tests.


Test Platforms

UnitTest ComponentTest Cold SystemTest Hot SystemTest Eyeball Tests
Dev Environment If the facility exists. Certainly for Business Rules, probably not for Human Tasks or BPM. Should be able to component test everything thru Java./ Same as for component tests. Not sure here. Beware of diminishing returns due to maintenance overhead. Ad hoc live testing might be useful, but probably not automated hot system tests.
Automated SystemTest No, not easy to automate. Yes, run every 10 minutes (cos they're fast)/ Same as for component tests. Possibly, depending on the ease of maintenance of the test harness. Nope, this is an automated test server.
IntegrationTest No, not easy to automate. Yes, run every 10 minutes (cos they're fast)/ Possibly kick off manually to check, but generally no need on this platform. Yes, if possible (and easy). Most definitely. This is the platform that customers can see (if you're 'Agile').


Test Phases

The number and sequence of test phases will vary from project to project. For larger scale projects with complex test and integration needs, there will be more phases. In our strategy, it just so happens that the test phases map on to the environments directly.

  1. Local Development: As developers code up in a fast-cycle test-driven fashion, this test phase is repeated many times a day for both unit, and (less so) component and system tests.
  2. Factory Acceptance: This phase is about qualifying the various software products. In an agile environment this might happen frequently or even continuously.
  3. Integration: Associated with deployment into the target platform, this is where interaction with external systems, hardware, middleware, networks, and so on. In many organisations this phase might be equivalent to 'Pre-Production'.

Other stuff