This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: SOA Testing
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
The question of testing has been gaining quite a bit of traction lately in the whole SOA context. Jimmy's been aggregating quite a bit of it. 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?
Previous Topic
