Common use of Extension by components Clause in Contracts

Extension by components. the Japl language‌ As mentioned in the introduction, the basic idea for unit or component testing is to test the component in isolation. The production code that represents the environment of the component is replaced by some test code which investigates the component by interacting with it. Since we aim at a model-driven component testing approach where component tests are usually derived from formal, hence rather abstract, specifications, we are in particular interested in testing techniques where a test does not rely on or aim at implementation details of the component but where a test only deals with the component’s effects on its environment. In order to investigate the means by which a component might have an effect on its environment, we extend our Java-like language with constructs that allow for discriminating component and environment code. This is done by integrating a notion of components into our language. A component is basically a set of classes. Classes of one component can be imported by another component (or by the program). A crucial point is here that importing a class is not realized by importing the code of the class definition. Instead, we formalize the operational semantics of a program in absence of the code of imported classes. This enables us to identify the most general characterization of a component’s influence on its environment, only assuming the interfaces of its classes. In this section we will extend the Java-like language with the notion of com- ponents. The extended language will be used in subsequent chapters where we will refer to it as the Japl programming language. Conceptually, Japl supports components, in that it allows programs to import externally defined classes. This means, a program might instantiate and call methods of classes which are not part of the program’s code but are assumed to exist in some other component. While the entailed syntax and typing modifications are quite simple, the operational semantics has to be given in form of an open semantics. In other words, we have to formulate the operational semantics without the code of the externally defined classes. The section is followed by a formal description of our testing approach given in context of our extended language.