Composite applications are made up of discreet services that have been tried and proven reliable, but building an orchestration that incorporates services that come from several sources, some of them outside of the company, could introduce testing hazards beyond just bad output. For example, let’s say that your business has a process that includes activities to run a credit check with an external credit agency or to schedule a package delivery with an external shipping service. When doing either of those tasks, we are introducing into the process two elements that can’t be easily tested live, simply because we don’t own the services internally.

Many processes also include delays or timeouts that are built into the process – this can further complicate matters, so testing each run-through of the application could take days. Besides these external factors, there are also internal processes that are in heavy use for other applications that are subject to changes and downtime. What you’re left with is few, if any, services that are easy to test.

Meanwhile you have out-of-band events, correlation, and other factors that present challenges to testing composite applications. The need to pay extra attention to these risk factors introduced by building applications from loosely coupled services doesn’t diminish the value of building standards-based composite applications, but a methodical and visual system to address these factors can extend the value even further.

In fact, unit testing for BPEL-based applications doesn’t have to be harder than testing any other kind of program. If you take a few reasonable steps you’ll have the information you need to confidently revise and deploy your standards-based composite application using a test-first methodology.

A clear first step is to take the process offline. For example, if your application calls for a credit check, it may be impractical to send 10, 100, or 1,000 requests to the credit agency while you’re testing. This can be done by collecting the actual responses created by live use of the service or generating sample data on your own to represent both the expected responses and all likely alternate responses, like responses that indicate a failure or responses that contain unexpected data. By using sample data in place of actually calling live services you can safely run process tests and be guaranteed of the expected outcome.

At this point you’re ready to run your suite of process scenario tests. The best way to understand the flow of activity and how problems develop is via a visual representation of where scenarios have passed, failed, or reached an unknown state. For example, displaying a report showing that out of 100 scenarios, 67 passed, 30 failed, and three reached an unknown state. This will help you find the problem areas and avoid putting a band-aid on certain symptoms when the real problem is somewhere else.

Finally, you need to annotate the results to pinpoint the problems further. So, of the 30 failures detected, you’d want to be able to visually depict where exactly in the process orchestration the failure occurred. From there, you’re armed to fix the issues and retest the application until all of the results are as you expect and any failures are dealt with to your satisfaction.

Many architects believe that testing composite applications is extremely difficult, or even impossible. However, if the correct steps are taken, that stigma can be erased, and testing composite applications can be just as easy as testing other any other program, and testing is crucial to gaining maximum benefit from your SOA and composite applications.