SOA Testing

The question of testing has been gaining quite a bit of traction lately in the whole SOA context. The catchall question, “how do I test my SOA?” is much too generic though.

First of all, we have to specify what kind of testing we’re talking about. Functional, non-functional, load, usability (services can have a UI) – each is approached differently. Second, we have to define what it is we’re testing. Are we trying to test the architecture, as the term “SOA testing” suggests, or are we focusing on testing a specific service?

Practically, architecture cannot be tested. The most common “test” performed on architecture is an inspection of use case realizations. By examining the way the system is going to be used in various scenarios, and tracing the flow through the elements that comprise the system, we can get a feel for how well the architecture supports a use case. If we see that a certain use case realization is cumbersome, or involves parts of the system that do not appear to be directly related to the use case, we might say that we found a bug in the architecture (if we really tried to use testing terminology). However, this process is really just a part of coming up with the architecture in the first place, before a single line of code is written. This doesn’t seem to jive very much with the spirit of “SOA testing”.

So, we’re back to how to test a specific service, once we decide what kind of testing we want. If we look at one of the important changes services brought to the structure of a system we can see that services represent a different style of division of functionality than components or objects. Their interfaces are different – message based. They manage their own data; which means we have to include state-based testing. When it comes to load testing, or usability testing, its hard to see what impact the decision to divide a system up into services (instead of components) has.

So, given that we’re going to want to perform functional, state-based testing on our services, we’re going to have to “exercise” them using the same kinds of communication found in a production environment – by using a bus, be it ESB or otherwise, to send to, and receive messages from the service under test. There’s also another level of testing that warrants examination in the service landscape and that is unit testing. What parts of a service can be unit tested, and how?

All the details, and more, coming soon :)

Posted by Udi Dahan at 04:48 PM  Permalink