Smalltalk and Object Orientation: an Introduction - Free

From the scenario that a person might have a birthday and therefore receive the message birthday,
and from examining the source code of birthday (and incrementAge) we can obtain the thread in
Figure 23.2.
birthday
incrementAge
age
age:
age instance
variable
Figure 23.2: A thread of execution through an object
23.1.3 Object state
Another point to bear in mind when testing a class, is that both instances and classes have state. For
example, a class may have a class in stance variable which is used to keep a record of the number of
instances which have been created of that class. This information may be used purely for book keeping
or may be used to limit the number of instances created. In the latter case, a test needs to be performed
which sets the counter to its limit and then a new instance should be requested. This could be done,
either by creating the required number of instances, or by manually setting the counter to the
appropriate value (e.g. by using the debugger or inspector).
It is also important to remember that although a method has been tested in the context of a state
instance, it is possible that some unintended sequence of message sends could result in the method being
executed with the object in an unin tended state. It is therefore not possible to test individual methods in
isolation thoroughly, nor is it sensible to ignore the state of the object when performing these tests. It is
of course quite possible to ignore the state, however the tester does so at their peril.
23.1.4 Private methods
Some methods are defined such that the user of the class is never expected to see them. This may be
because they do some housekeeping which is local to the object (for example the initialization method)
or because they provide facilities which are relevant to the internals of the object and not to the external
interface to the object In Smalltalk, this method hiding is not enforced, it is usually left implicit (unlike
C++ or Java in which the equivalent of privat e methods really are private and are not available as
external messages). For example, in VisualWorks Smalltalk this can be done by placing the appropriate
set of methods in a protocol entitled private or private-*. The convention is that a user of this class is not
expected to use or to need to know about these methods. This is useful from a testing point of view as
the tester can test the individual execution of these methods in a black box fashion. They can also use
the approaches described above to perf orm white box testing. However, it also means that a user of the
class, if they so wish, can call these methods. As this is not what is intended it is arguably reasonable to
ignore this scenario. However, it may be wise in some situations at least to know what the effects will
be and whether the object’s methods will respond in a meaningful or at least well defined manner. For
example, it may be useful to know what will happen if another object sends the message initialize to the
current object at some point after the object has started to be used.
23.1.5 Pool variables
An additional problem with testing classes (as opposed to unit testing in other languages) is the presence
of pool variables. These are rather like limited scope global variables. They are common to a set of
classes and may affect the operation of these classes. As any one of the classes associated with the pool
can change their value it is possible for one class (or its instances) to have a profound effect on the
operation of a completely different class or its instances elsewhere in the system. This is something
which requires careful thought.
191