Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.
Hannah Smalltree, Editorial Director
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.)
This was first published in July 2008
