Challeges in SOA test automation

Today, I like to mention about testing a service in SOA world.

I don't think I need to explain what is SOA or what are the benefits of Service Oriented Architecture. You can find good articles and papers online.

So let's talk about service testing. I think there are several different kinds of service in SOA world. One of them would be bottom layer service which is normally a wrapper for database. Another one would be sort of middle layer service which consumes other bottom layer services.

In my opinion, normally the motivation for the bottom layer services is that many different parts of the system accessing this one giant database and managing this DB is getting out of control or already out of control. And the solution that architects and business people sit down and come up with is creating a wrapper service for that DB and do all kind of optimization and throttling.

So when we develop this wrapper(bottom layer service) for DB, normally the business logic is already implemented and used in the system. Now, it sounds simple to move this business logic to one place, but the reality is not as simple as it sounds.

First, going through legacy code and figuring out the business logic is really complicated work. What is available in legacy code might not be available in wrapper service. There're lots of corner cases handled in different kinds of conditions, and so forth.

Second, combining these different business logic to common functionality in the service is another challenge. You cannot simply copy the business logic of legacy code to the wrapper service. Sometimes, you need to come up with some new logic that handles DB more efficient or new logic that returns better sets of data.

Third, the testings is another challenge. So if the new service has some new logic that handles DB more efficient and accurate than existing legacy code, then output of the service might not be the same result as current system produces.

Do you see the challenge here? Now you don't have something to assert to. Existing system inputs and outputs are not the same as new wrapper service returns. And your new service might have logic flaw. So you need to make that the new service is going through the logic as designed and returns correct results. And also test the integrity of the result. If you have billions of data in your DB, it's just impossible to handle every inputs and outputs in your test case.

I'll try to find out best approach for this kind of testing challenge. What do you think? I'll post what I think in next blog.