SOA Testing

Question

How is SOA testing different than traditional testing of application

Answer 1

As each "service-provider" should have a standard, business-oriented interface (usually provided with WSDL technology), then the following properties might be different:

• The services being provided shouldn't change from revision to revision of the modules, unless you are making extensive changes to the business itself.

• A module shouldn't care who it's clients are, which makes module-testing easier.

• Ideally, the services being consumed are provided by a directory, and not hard-coded into the modules; if this holds, then testing parts of the system -- some modules but not all -- becomes much easier as well.

Edit:

• And, as others have pointed out, you need to test conformance to the specification, and not if the present components of the system work with each other. For example, a web page might be displayed ok by Internet Explorer, but still not conform to the specification, and thus be unusable with other browsers. When you go SOA, you expect to be able to replace providers of a service seemlessly.

Answer 2

The think you must remember is that within an environment where there are a lot of dependencies, you must have all that dependencies mapped and all paths must be tested.

Having services, they must be used with a lot of clients, so every client should follow the test cases.

With services, you also need to pay attention to network issues. Make the traditional tests putting a lot of traffic in the network and switch off to see how it works.

Besides that, having services do not require other kind of different approach. Just control all the inputs and outputs.

Answer 3

Few (valuable?) advices:

The definition of services should lead to the use of Mock framework, to validate your services consumers without relying on the implementation of the providers.

Check the robustness of your consumers: what happens when messages are lost, when a service provider is unavailable.