Smalltalk and Object Orientation: an Introduction - Free

23.4 Self testing
An approach, suggested by Charles Weir of Object Designers Ltd., would be to provide facilities which
enable code self-testing within Smalltalk. A simple technique is to make the code do its own self-testing
using assertions. This is a code statement that is always true; it tests that the code is behaving as
expected. If the statement is false the assertion stops processing to allow debugging.
An implementation of assertions in Smalltalk is
assert
self value ifFalse: [self halt].
This method should be added to the BlockContext class and allows the developer to verify
assertions wherever required, for example:
[range first == 1] assert.
Of course in the released version of the system, these tests ar e redundant and waste processing time. So
they could be replaced by a null version of the method:
assert
self.
The overhead of the extra method dispatch is relatively small; of course if it is still significant, we
could write a utility to find the senders of the method and to comment out the assertion statements.
Assertions are particularly useful for testing preconditions, postconditions and class invariants. The
Syntropy design method makes extensive use of such assertions [Cook and Daniels 1994 ]. It would
therefore be possible to use the assertions identified during the design as the basis of the assertions to
place in the Smalltalk code.
This approach could be taken further with the introduction of universal quantifiers (there exists and
for al l). This would allow expression such as if there exists a value x. The introduction of such
quantifiers is not without its problems but should be possible. In addition assertions could also be used
to ensure that the relationships between pre and post values during some operation is appropriate. Again
this would not necessarily be straight forward, but it should be possible.
23.5 Summary
Throughout the chapter, guidance has been given to ways to overcome the problems inherent in testing
object oriented systems. In the next chapter we shall consider a simple set of extensions to the basic
VisualWorks environment which greatly simplify the whole testing process.
23.6 Further reading
As there is so little written about testing object oriented systems, this section provides an extended set of
references on the subject.
In 1994 a special issue of the Communications of the ACM was published which focused on testing
object oriented systems [Binder 1994]. In this special issue a number of papers cover topics related to
object oriented testing. For example, [Binder 1994b] discusses design for testability in object oriented
systems which is a particularly important issue given the effects of inheritance, polymorphism and
particularly encapsulation on testing.
Other papers relevant to object oriented testing include [Beck 1994], [Hoffman and Strooper 1995],
[Hunt 1995], [Jorgensen and Erickson 1994], [Siepmann and Newton 1994].
The workshops on testing held at the OOPSLA conferences are also a useful source of references.
For example the workshop held as the OOPSLA ‘95 Conference. For more information contact Barbara
Yates, OOPSLA Workshop, 2002 Parkside Court, West Linn, Oregon, 97068 -2767, USA (Email:
barbara.bytesmiths@acm.org).
193