Testing Service-Oriented Architectures: A Primer for the Real World
Along with the benefits of an interconnected system come spiraling costs if the system runs out of control. When undertaking SOA, testing is a necessary form of risk-management — and Matt Heusser describes how to do it well.
The overall SOA effort should include requirements for how our systems interoperate; each of these becomes a use case for messaging.
We'll also want to do volume testing, soap opera testing, attribute testing (more about those later) and exploratory testing. Exploratory testing is just what it sounds like: learning about the product as you test, with the results from one action helping guide your strategy. To do that, you'll need to watch the messages that are sent to different systems, if not simulate them by hand.
But How?
Fundamentally, we are talking about testing a messaging system — making sure that the messages that go across the wire for every transaction are correct. If something does go wrong, was the problem at the sender or the receiver? It can be hard to tell. If there is a central "hub," it may have incoming and outgoing log messages to check. If your company is just integrating commercial, off-the-shelf software, you may be able to test using a tool like Empirix or TKO's Lisa.
If your technical staff is creating its own Web services, they should be able to create tools to send and monitor messages on the service bus. Once these tools are in place, you can record what messages go across the wire and the results, and use some kind of driver to "play them back"—a form of test automation. With such a test suite in place, adding a new service is relatively easy. Run all the old tests, record and run new tests, and see success. These tools will be especially valuable for attribute testing, which I discuss next.
Attribute Testing
The software may function, but how quickly does it perform each call? How how quickly is fast enough? And what happens at the end of the month, when the systems run billing in batch? If a customer orders a part, how fast does that order need to appear on a website? Minutes? Hours? We call these "ities" (scalability, security, reliability) attributes; thus the term "attribute testing."
Security, redundancy, failover, perfomance, load and volume—we should consider the risks of each, consult with management, and put these tests into our test plan.
Soap Opera Testing
If you've gotten this far, you probably realize that comprehensive testing is impossible. What we strive to do is the best possible testing with the time we are given, or, as Bill Hetzel put it so well "The only truly exhaustive testing is when the tester is exhausted." Our goal is not "perfect software," but instead software that is fit for use, or responsible testing.



