Testing service-oriented architecture requires thinking outside the box to the point that your test cases hit an application with totally unexpected input, argues Thomas Fredell, CTO of IntraLinks.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
“Try to test for things that you don’t expect to happen, he said in a new SearchSOA podcast. “That’s particularly important when you’re testing security aspects of an architecture. Make sure what you’re testing is not part of the expected flow.”
Fredell also recommends that architects assume that things will go wrong with their SOA implementation and plan for glitches.
“Architecting for fault tolerance, you assume what can go wrong will definitely go wrong,” he said. “If you’ve got a component of your architecture servicing requests, when that component fails, what does it fail over to, to insure that the clients of your service are not affected.
SOA requires thinking outside the box because it is different from monolithic or client/server applications in that you may not have control over all of the Web services interacting with your SOA application, the CTO said.
“The beauty and the risk associated with service-oriented architecture is on the one hand you can compose services and meet business needs very rapidly,” Fredell said. “On the other hand, you may only have control over one side of the equation, the side where the service is implemented. That may mean that people do things that you really don’t expect.”
Access an interview with Thomas Fredell on SOA and the Unexpected