A Framework for Testing Object-Oriented Components
, Carlo Ghezzi
, Alessandro Orso
, Mauro Pezzè
and Matteo Valsasna
EECS Dept. (M/C 154)
Dip. di Elettronica e Informazione
University of Illinois
Politecnico di Milano
851 South Morgan Street,Chicago, IL 60607
P.za Leonardo da Vinci, 32, I-20133 Milano, Italy
Phone: (312) 413-2296, Fax: (312) 413-0024
Phone: +39-02-2399-3638, Fax: +39-02-2399-3411
The terms “component” and “component-based software engineering” are relatively recent. Although
there is broad agreement on the meaning of these terms, different authors have sometimes used slightly
different interpretations. Following Brown and Wellnau , here we view a component as “a replace-
able software unit with a set of contractually-specified interfaces and explicit context dependencies
only.” A component is a program or a set of programs developed by one organization and deployed
by one or more other organizations, possibly in different application domains.
To date, many component systems are designed and developed using object technology. The same
is true of middleware architectures that support the deployment of components, such as Java Beans ,
CORBA , and DCOM . Although there is consensus that the issues in component-based software
engineering cannot be solved merely by object technology [4, 14], these technologies will clearly play a
fundamental role in the production of software components . It is quite likely that developers will
use with increasing frequency object technologies in the design and implementation of components.
For this reason, in the sequel we focus on testing of components that consist of an object or a set of
cooperating objects. In addition, we consider messages sent to a component as method invocations on
the objects contained in the component.
Programs developed with object technologies have unique features that often make traditional test-
ing techniques inadequate.