TABLE OF CONTENTS The previous sections have set the foundations for developing and using built-in contract testing. For the development, this is mainly from the perspective of the component developer or provider. The subjects of these previous chapters and sections can be regarded as a required entry criterion, as a prerequisite, for introducing, implementing, and using the technology, which comprises:
A sound development method such as the KobrA method that defines the
required quality criteria in the form of a quality plan, and thus a collection of test selection strategies,
the specification and realization specification of each component, ideally in the form of models, and operation specifications.
A well-defined architecture with clear identification of the components and their associations in terms of
static component relations that will receive removable built-in contract testing artifacts, and
dynamic component relations that will receive permanently built-in contract testing artifacts.
We can apply the principles of built-in contract testing in projects that are lacking all these prerequisites, but they alleviate the design and implementation of built-in contract testing considerably, especially with respect to the degree of automatism that we can introduce within such a methodological framework. Without sound methodological support it is much more difficult to come up with a sound quality assurance plan, though this is also true for any development activity in any project.
The next sections provide a step-by-step guide for developing testing interfaces and tester components at a high level of abstraction; lower level abstractions and implementation...
