TABLE OF CONTENTS Built-in contract testing addresses two of the three primary challenges in component-based software testing: low internal visibility of the tested object and component integration in various alien contexts that have never been anticipated by the object's original producer. The first issue is dealt with by the built-in testing interface that each reusable component is supposed to provide additionally to its original functional interfaces. Its design can be based on the externally visible states of the object, but more fundamental concepts such as assertions are also perceivable. In general, anything that makes a component more testable through external clients is fully in line with what built-in contract testing stands for.
The second issue is addressed by the built-in tester that each reusable component should readily provide. This contains tests that represent the object's expectation toward its associated server components and the underlying run- time system that in fact also represents a server component, albeit an implicit one. Built-in tester components are more fundamental to built-in contract testing because they assure that two components that have been brought together syntactically will also interact correctly in terms of their semantic contracts.
Tester component and testing interface will together make sure that a reusable component that is brought into a new context will behave according to what the context is expecting, and that the context will behave according to what the reusable component has been developed to expect. Built-in contract testing greatly alleviates the effort of integrating alien components in a component-based...
