The unit testing term in this context could mean two different things: The first is Unit testing at the application implementation layer (e.g. JUnit for Java, NUnit for .NET, etc.) and is used to validate component (often class) functionality for the underlying implementation back end of a SOA, and provides bottom up quality.
The second meaning is the practice of creating and maintaining tests at the individual service level in SOA and at the message layer, which provides top-down quality to validate functionality for each atomic service level, outside the context of a business process.
Now, having described both unit testing types, it is critical that they are both:
a) created and maintained as repeatable, automatically re-runnable tests
b) executed automatically as part of a continuous lifecycle process at best, or easily on-demand whenever impact of a change needs to be assessed
c) institutionalized as a quality policy that enumerates and quantifies the testing. For example, use coverage at various levels: requirement test coverage, code, and defines policy on the kinds of test cases that need to be present--such as positive, negative value cases and how they need to be parameterized with a variety of data sets.
d) monitored with a visible process that trickles the results back up to the appropriate level as a quantitative measure for SOA quality (e.g. status dashboards, registries, etc.)
Dig Deeper on Topics Archive
Related Q&A from Rami Jaamour
Rami Jaamour discusses how to go about planning on using emulation in order to simplify complexity or replicate the behavior of systems that are ... Continue Reading
Rami Jaamour discusses the best place to begin when building a testing system for SOA and how to establish a quality policy as part of the overall ... Continue Reading
Rami Jaamour discusses the ways in which both business and IT people can work together in the SOA testing processes. Continue Reading