Smalltalk and Object Orientation: an Introduction - Free

22.3.2 Incremental testing
Incremental testing is one obvious answer, i.e. we don’t want to re -test the whole class if we don’t need
to, only those elements which have been affected by the additions in the subclass need to be tes ted. Of
course this is the key issue here: what determines whether or not we “need to” re -test a subclass. One
answer is that it is the properties of the class which are affected by the subclass, including which
instance variables may be altered and which methods may be directly or indirectly affected, which
determine what should be re-tested. For example, a directly affected method may be one which is called
by a (re)defined method in the subclass or which directly references an instance variable which is
modified by (re)defined methods. Indirectly affected methods are much harder to identify. They are
methods which may be affected due to a chain of interactions. For example, suppose that a method “ a”
references an altered instance variable and modifies ano ther instance variable. This results in a second
method operating in a different way generating a different result which is used by a third method. The
third method is indirectly affected by the original change in the instance variable. In the worst case,
every element of a class may be affected in such a way. In such cases, either the whole class must be retested
or the developers must use their own intuition and experience to decide how much testing is
required.
A subtlety which can often be missed is t hat although an inherited method has not been changed, a
method which it calls may have been redefined in the subclass. Thus the inherited method is directly
affected by the subclass and must be re-tested.
However, we want to be sure that any inherited fu nctionality has not been adversely affected in an
unanticipated way (note that this implies that we have some sort of specification against which we can
compare the functionality of the class). We must therefore also consider some form of regression
testing. This can be achieved by defining an appropriate set of regression tests on the class side of the
root superclass. These tests can then be performed whenever the root class or one of its subclasses is
changed in anyway. Ideally these tests should include their own evaluation so that a report can be
generated (to the Transcript or to a file) stating the result of the tests. If appropriate, additional tests can
be defined (in subclasses of the root superclass) to test the added functionality. If new tests a re defined
each time the functionality is extended or modified, then the tests on the class side also act as a
repository of testing knowledge which can be exploited by future users of the classes without the need
to understand their full functionality.
22.4 Abstract superclasses
Abstract superclasses bring together common features, which are to be used in many subclasses.
However, from a testing point of view they are a difficult problem. The definition of an abstract
superclass is a class which is never intend ed to be instantiated and which does not provide, in its own
right, enough functionality to be useful. Given these two features, it is extremely important to test
abstract superclasses thoroughly. However as they do not provide enough information to create an
instance of the class, it is impossible to test the class directly. The tester should provide a subclass
which acts as a test harness for the facilities defined in the abstract class (such a class can be easily
removed from the Smalltalk image).
The test subclass might provide a wide range of facilities. For example, a method may be defined
which sets the state of the instance such that a particular method can be called and then sends a message
causing the method (inherited from the parent class) to be executed.
Note that testing the abstract superclass does not mean that exhaustive testing of the methods in the
subclasses, which inherit from it, is not required. As each subclass has changed the context within
which the method will be run, the same appr oach to testing as discussed in Section 3 must be
performed.
22.5 Encapsulation
Encapsulation is a great bonus from the point of view of the user of an object - they do not need to know
anything about the object’s implementation, o nly what its published protocols are. This also means that
the developer of the class knows that any potential users will have to come through the front door etc.
185