TOPL (Testing Objects Pattern Language)
Author: Donald Firesmith
Although there is always a considerable risk associated with making
predictions, I am convinced that object-oriented patterns will be viewed as the
most important concept in the object community during the 1990s. For example,
within a single year of its publication, the book Design Patterns [Gamma et al.,
1994] has been recognized as the number one book in the list of top ten all-time
classics in the object technology field [Bilow, 1995]
According to the Dictionary of Object Technology [Firesmith and Eykholt,
1995], a pattern is "any reusable architecture that experience has shown to
solve a common problem in a specific context." A pattern language is a
consistent collection of related patterns gathered together to deal with a
specific problem domain. Several important object-oriented testing techniques
have been captured in the form of test patterns. These patterns have been
collected together to form PLOOT, the Pattern Language for Object-Oriented
Testing, which has been developed specifically to deal with the following
general issues that differentiate object-oriented testing from traditional
- Unit testing is the testing of classes, typically indirectly by means of
their objects. This is because (1) classes are the basic units of design, (2)
classes are usually source code entities whereas objects are run-time entities
that may be executed, and (3) individual operations within the class can not
be tested in isolation because they depend on the environment of the class
(e.g., other operations, properties, exceptions, assertions, etc.).
- Objects are essentially software blackboxes that hide their encapsulated
properties (e.g., attributes, links, component parts) and hidden operations
behind an interface of visible operations.
- Objects may exhibit externally-visible state behavior (e.g., a pop message
sent to an empty stack raises a stack empty exception rather than returning
the top entry).
- Objects collaborate via messages and exceptions, whereby messages may be
dynamically bound to polymorphic operations. A unit test case is therefore
typically a test message (with or without arguments) sent to an object under
test that is in a specific state rather than test data sent to a function.
- Objects are defined by means of classes which are related via inheritance
- Integration testing must take into account collaboration, inheritance,
aggregation, and attribution as well as patterns and mechanisms.
- An iterative, incremental, parallel development cycle is often used in
which testing is performed incrementally, must be repeated often, and is begun
earlier in the project schedule.
This chapter has presented the initial version of PLOOT, a pattern language
for the testing of object-oriented software. Future versions of PLOOT will add
additional patterns, especially in the area of integration testing, to the
following current patterns:
- Built-in Test Operations. This is a pattern for automating the complete
whitebox unit self-testing of classes while bypassing encapsulation.
- Mixin and Join Test Hierarchies. This is a pattern for automating the
complete whitebox unit testing of class using mixin and join classes to bypass
- Friends Test Hierarchy. This is a pattern for automating the complete
whitebox unit testing of class using friends to bypass encapsulation.
- Separate Test Driver Hierarchy. This is a pattern for automating the
complete blackbox unit testing of class.
- Paired Message Sequences. This is a pattern for performing state-based
blackbox unit testing of classes specified via axioms in terms of pairs of
message sequences that should transition equal objects into equal objects.
- Transition Trees. This is a pattern for performing state-based blackbox
unit testing of classes in terms of transition trees base on state transition
- Operations that Delegate. This is a pattern for testing operations that
delegate responsibilities to other classes
- Dependency-Based Testing. This is a pattern that determines the optimal
test order for classes based on dependency relationships among the objects.
- Assertions and Exceptions. This is a pattern that supports class level
debugging by embedding assertions and exceptions in the classes under test
- Use Case Testing. This is a pattern for the acceptance testing of reactive