Smalltalk and Object Orientation: an Introduction - Free

made worse, because the symbol held in aVariable (which is the name of the message to send to the
item) is determined by anObject which is an object passed into this method. We therefore do not
know:
1. What the contents of aCollection will be
2. Which classes must respond to the message passesTheTest
3. Which instances are likely to result in the ifTrue block being evaluated (this is context
dependent).
4. What the message to be sent within the ifTrue block will be (this is content dependent).
5. Which objects must respond to the message we don’t yet know.
It could be argued that this is true, but irrelevant. However, the point is that a number of the above
issues would be resolved by the co mpiler at compile time in other languages such as Ada or Pascal.
These static compile time checks can identify what type of object will be held in the aCollection, if the
type of object receiving the message will understand that message etc. Where as in S malltalk, it is left
up to the developer to ensure that no problems are likely to occur.
As you can see from this very simple (although slightly contrived) example traditional static test
generation techniques, although of use in object oriented language s such as Smalltalk, do not provide
the whole answer. In the example above, the problems are due to the dynamic typing of Smalltalk and
the late binding and polymorphism of object oriented languages.
22.2.2 What makes it hard?
Part of the problem for object orien tation is that space of possibilities is so much greater. For example,
not only are we concerned about objects sending messages requesting that other objects run specified
methods correctly, we are also concerned with which class of object will receive the message and which
class of object sent the message as this will therefore have an effect on which method will be used.
These issues are related to the polymorphic nature of object oriented languages and the use of
abstraction and inheritance as a basic system construction tool.
In addition encapsulation leads to a fundamental problem of observability; as the only way to
observe the state of an object is through its operations. This is fine for black box testing, but makes
white box testing extremely diffic ult. This problem is compounded as traditional control flow analysis
techniques are not directly applicable as there is no definite sequential order in which methods will be
invoked. That is, another object may request that a method is executed at a point which cannot be
statically determined (see example in introduction). Indeed, as the state of the object may affect what
the method does, it may not even be possible to determine how the method will behave. Of course this
does introduce the issue of “what is correct behavior”, however we will leave the issue of “correctness”
until a later section.
In traditional programming languages the basic unit of test is usually taken to be procedure or
function. However, it should be seen from this brief discussion t hat, the object oriented equivalent i.e.
the method, cannot be taken as the basic unit of test. It is affected by the state of the object, possibly by
the state of the class (if the class has class variables), may interact in unforeseen ways with other
methods and may rely on methods defined elsewhere in the class’s superclass hierarchy.
Inheritance also affects testing and introduces the following question “after a change, to what extent
should the code currently in the system be re -tested?”. In a traditio nal programming language it is
usually quite straight forward to identify what parts of the system code are affected by some change. In
an object oriented system it is far less obvious.
The implication of the above is that in object oriented programs, suc h as those implemented in
Smalltalk, the basic unit of test must be considered to be the class. That is not to say that care is not
given to exercising individual methods within a class, merely that the individual methods should not be
treated in isolation.
22.2.3 Why a lack of emphasis?
Part of the reason for the lack of Smalltalk testing literature or tools is probably due to the background
of Smalltalk. In the past it was often used as a single (or at most a few) developer’s language. It was
often considered to be a personal development environment or a good prototyping tool. However few
183