Smalltalk and Object Orientation: an Introduction - Free

However, for the tester of the class it is both a benefit and a drawback. It is a benefit bec ause the
encapsulated object is clearly designated for unit testing. That is, it is clear what the boundaries of the
class are, i.e. anything that is not in the class is in another class and thus does not come into the picture
(from the point of view of unit testing). It is therefore possible to test the unit in isolation.
22.5.1 Black box testing
Encapsulation therefore promotes black box testing. Black box testing can be carried out in the normal
way with the addition that the state of the object (and possibly t he class) must be taken into account.
Black box testing (also called specification based testing) is aimed at testing a program against its
specification only. That is, the class should be tested regardless of the way in which it has been coded. It
is usually accomplished, even in object oriented systems, by identifying a set of messages to send to the
object and the parameters to use with these messages. The results of sending these messages are then
compared to the original specification (assuming one exi sts). The product of this comparison is then
used to determine if the class has passed the test or not. In general, if some results are not as expected
further testing would be used to determine the actual behavior of the class. A decision would then be
taken to determine what action was required (i.e. modification of the source code or if appropriate,
modification of the specification).
22.5.2 White box testing
Although encapsulation promotes black box testing, it can make white box testing much harder. White
box testing (also known as program -based testing) is complementary to black box testing. It consists of
examining the internal structure of a piece of code to select test data which will exercise that code
thoroughly either because that piece of code is crit ical or to gain confidence in the code to eliminate it
from suspicion (for example if you are attempting to track down the source of some undesired
behavior).
A problem with encapsulation is that while it is entirely possible to view the source code and
identify the tests to perform, it is not possible to access the instance variables of the object directly, nor
is it usually possible to monitor the execution of the methods externally to the object.
Of course in most Smalltalk environments you could use t he debugger and the inspector to examine
the source code during execution (and indeed this is the intention of these tools). However, using such
tools presents problems for both traceability and accountability. Thus it is not possible to trace the tests
which have been performed during a project nor is it possible to record these tests and their results for
later quality audits. Of course, you can require the developer to note what they are doing, but this is
nowhere near as good as having the system do it for you automatically. This approach also fails to
support repeatability of tests. That is, once you have completed your testing, it is not possible to re -run
the tests and check the results following some change to the class.
22.5.3 Overcoming encapsulation during testing
In Smalltalk it is possible to work around the problems imposed by encapsulation in a number of ways:
22.5.3.1 Use of the halt message
Smalltalk provides a halt message which can be sent to an object. This will cause the obje ct to stop
executing at that point and allow the user to enter the debugger. The debugger will then allow the user
to view the method that is executing as well as the state of any instance and temporary variables
This may at first seem intrusive, as the de veloper is modifying the source code of the method by
adding the halt message. As has already been stated this is not desirable. However, in this case, it is
possible to control the method’s execution through the debugger. This means that the developer can
ensure that the intended operation of the method remains unchanged before attempting to identify the
behavior of the method under test situations. Thus this approach may not be as intrusive as would at
first appear.
It is unfortunate that the debugger is so named, as it is not only useful for debugging systems, it is
also a particularly useful tool for white box testing. This is because, once you have entered the
debugger (e.g. by introducing a self halt message into the source code of a method) it is pos sible to
186