TABLE OF CONTENTS The philosophy behind all built-in testing concepts is that an upfront investment on verification and validation infrastructure pays off during reuse. In component-based development, this follows the same fundamental ideas of gaining return on testing investment through reuse of the built-in testing artifacts. The more often a component will be reused, the higher is its rate of return, and this applies to its functionality as well as its testing. This is the case only if the testing artifacts are permanently built-in, and are always deployed, or at least purchased, together with the component.
The objective of built-in contract testing is to ascertain that the environment of a component meets the component's expectations, and that the component meets the environment's expectations. These two views are the only things that can change in component integration. This is illustrated in Fig. 4.1. Typically, if we bring components together to form a new application, we will find a number of individual units that are nearly good enough for the purpose. It is extremely unlikely that we will find all components in forms that exactly match all other components that we are going to reuse. Normally, we will have to perform some syntactic and semantic mapping at the boundary between the deployed component and the component infrastructure in Fig. 4.1. In Chap. 2, I explained how this is typically done in a development method. In order to achieve this mapping we cannot usually...
