Smalltalk and Object Orientation: an Introduction - Free

22.6.2 Extensibility of hierarchies
Another problem associated with polymorphism is presented when an operation, which possesses one or
more parameters which are polymorphic, is being tested. That is, the operation can be called with a
range of different types of object as a parameter. For example, a parameter may be assumed to be a
collection, however it could be a set, a bag, an array, a list, a sorted collection or an ordered collection.
Each of these have specific features which may or may not affect the operation of the method. They
may also contain elements which are of any type, which in turn may or may not affect the method’s
behavior.
As testing a method consists of checking its effects when executed for various combinations of
actual parameters, a test suite must ensure that all possible input types are covered. This of course
implies that some form of specification exists which specifies the acceptable range of input types.
However, it is impossible to plan a set of tests in which you check all possible parameter values for a
method. This is because the range of different types of o bjects which could be presented to a method is
huge in Smalltalk. Remember that the hierarchy of classes is very large (e.g. every class under
Object) and is freely extensible. For example, I can define my own stack and queue collection
classes. However, even if the method I am testing includes a test to see if it has been presented with an
instance of a collection class, it could easily encounter a type of collection class for which it was never
designed. Remember you (or anyone else) can extend the set of collection classes whenever you wish. If
the method is part of a class which is to be provided as part of a set of “highly” reusable classes, either
within a single project or for external use, this is a significant issue.
22.6.3 Heterogeneous containers
As has been briefly mentioned above, there are many classes which are designed to hold elements
which may be any instance in the system. In Smalltalk, this means that they can hold instances of
classes, classes, metaclasses etc. If the tester is considering a met hod which will be applied to, or will
consume, the members of such a heterogeneous container (e.g. a collection), it is almost impossible to
ensure that a complete range of tests has been performed. For example, it may be assumed that all the
members of su ch a container are conventional instances of user defined classes, however there is
nothing to stop the member of one of these containers being a class or the system dictionary etc.
In such situations care must be taken to ensure that reasonable usage of the method has been tested.
In other words, with reference to the classes specification, assumptions must again be made, this time
about the use of the method. Again, these assumptions should be documented so that they can be
challenged if necessary at a later date.
22.7 Additional Smalltalk specific features
22.7.1 Block evaluations
Blocks introduce another complexity to the testing process which is particular to Smalltalk. Not only are
they more difficult to test physically (it is more difficult to get hold of them i n isolation), they also
execute in the context within which they were created (rather than the context in which they are
evaluated). This second issue is important because in many situations a block is defined in one place,
and then passed as a parameter t o another place, where it is evaluated. If the receiving method is being
tested, it is impossible to conceive of all the contexts in which the block could be created and therefore
impossible to produce a comprehensive test suite. Again, care must be taken to test the receiving
method against its specification and not the assumptions which this led to.
In addition when they are examined in the debugger, they are treated in a different way to general
Smalltalk code, which makes it more difficult to follow the thread of execution. Instead of immediately
stepping through the code in the block, it is necessary to step down into the value method and then into
the block. It is all to easy to step over the block and fail to see the result.
188