TABLE OF CONTENTS In the literature, built-in testing typically refers to all concepts that are added to a component's code for facilitating testing or checking assertions and conditions at runtime. Built-in testing is usually not part of the original functional requirements of a component, and it does not stay incorporated in the code beyond the release of a component. But the main argument of this book is about exactly that: the development of components with permanent built-in testing, seen as an integral part of the components right from the beginning of their construction. There are some disadvantages under certain circumstances of leaving testing artifacts built-in permanently; but we will initially concentrate only on how we can apply built-in testing techniques in component engineering and component-based software testing, and will later on discuss how to organize them so that we may get rid of them again easily if we find them troublesome.
In the following, I will describe the two primary technologies of built-in contract testing, assertions and built-in testing, in more detail.
Built-in testing is not a new concept. Among the first built-in testing concepts in software engineering were assertions, although we cannot really call them built-in testing. An assertion is a boolean expression that defines necessary conditions for the correct execution of an object or a component [16], [141]. Assertions in software follow the same principles as the self-checking facilities that are readily built into hardware components. Whenever the boolean expression of an...
