Smalltalk and Object Orientation: an Introduction - Free

control the execution of the method in a number of ways. For example, a tester can change the state of
an object or the input parameter values using the inspectors at the bottom of the debugger. They can
control the execution of the method either by stepping through the method a line at a time, descending
into methods called by this method or proceeding to run the whole method as though the debugger had
never been entered. By default the tester controls the execution of the method from the point
immediately after the halt message. However, it is also possible to re-run the whole method.
22.5.3.2 Subclassing the test class
A more object oriented approach is to define a test subclass for the class being tested (this approach has
already been mentioned above). The tester can then define an appropriate set of test harness methods
which exercise the class in the desired manner. As the test harness methods have the same ability to
access the state of the object as the methods under test, it is possible to determin e the object’s state
before and after a method is executed. The results of these tests can then be written to the Transcript and
/ or to a file. If the results are written to a file, the tests can be re -run at a later date and the new results
compared with the previous results. This is cleaner than writing print statements within the source code
of the methods to be tested, however it does not allow the internal operation of the methods to be
monitored as closely.
To monitor the actual execution of the desi red methods, it is possible to place a self halt.
message just prior to any super message. This invokes the debugger and allows the developer to step
down into the super method’s code. For example:
age
self halt.
super age.
Of course, in practice a com bination of all of the above may be necessary to accomplish both black
box and white box testing effectively.
22.6 Polymorphism
Polymorphism is the ability of objects to send the same message to instances of different classes which
do not have a common superclass. It is made possible by the dynamic binding of messages to objects.
That is, it is only at run time that it is possible to determine to which object the messages will be sent.
From the point of view of testing, there are a n umber of problems associated with polymorphism. Each
of these is discussed separately below.
22.6.1 Undecidability
Polymorphism allows the programmer to specify which message will be sent to an object, but not which
object will receive that message. This will onl y be determined at run time. It is therefore not possible to
provide any form of static check to see that the message will be “understood” by the object (other than
checking that at least one class somewhere in the system will respond to that message). In addition,
even when it is known that the object receiving the message will understand the message (e.g. all
objects in Smalltalk understand printString), it is not possible to identify which version or
implementation of the method will be executed. That is , the tester will know that the object will
understand the message printString, however, which version of printString will be used will depend on
the class of the receiver. It might be that defined in class Object, that defined in class Collection
etc.
It is therefore impossible for the tester to know what would be an appropriate range of tests for a
polymorhpic message expression. They therefore have to make assumptions about the range of objects
which are likely to be sent the message. In some cases this range may be very large indeed. In such
situations it is necessary to produce one or more class hierarchies for different implementations of the
method. These trees can then be used to identify those classes in which new definitions of the method
are provi ded. The assumptions being used in the tests should, of course, be made explicit in the test
report, so that they can be challenged if it is felt that they were inappropriate.
187