Smalltalk and Object Orientation: an Introduction - Free

people considered it suitable for constructing industrial strength systems in. The reasons for this have
already been considered in the introductory chapters of this book.
As t he types of systems being constructed were experimental, the tools available made code
debugging easy and could be done even when the implemented system was executing. This led many
people to design the overall system, roughly specify the components, imple ment them and test the
resulting system (not the components) using the user interface. If the system failed (at any time
including once development was complete) then a quick fix could sort out the problem. This approach
can work well for a single develope r-user, non critical, application where the majority of the system is
the user interface. However, for serious development this approach is inappropriate.
Smalltalk applications require testing just as any other software requires testing. Indeed the type o f
testing normally applied to traditional programming languages is also required by object oriented
systems. However, object orientation imposes unique requirements on the testing process. Why these
requirements exist and how they can be handled is the subject of the remainder of this chapter.
22.3 Inheritance
Inheritance is a fundamental feature of object oriented programming languages. However, it is both a
blessing and a curse. For example, many programmers believe that they can inherit many of the features
they require in their new classes from existing classes (and often they can). However, they also tend to
feel that it is not necessary to test those features they have inherited because they have been tested very
many times before (both by the system develo pers and by the many thousands of users). However, this
is misleading because in defining a new subclass they have changed the context within which the
methods will execute at least in the subclass. The problem is that each new subclass may not require any
re-testing and may very well function acceptably, but you are relying on a continuing hypothesis. Of
course this hypothesis may have held many times before, but there is no guarantee that it will hold this
time. Interestingly, the same problem also occurs with Ada generics. In this case each instantiation of
the generic package may work as intended but equally this time it may fail.
22.3.1 The effects of inheritance
There are a number of ways in which inheritance can affect the testin g required in a subclass. The
following list summarizes these and lists the type of testing required:
Adding functionality . For example, by adding new methods. In these situations, the tests should
concentrate first on the new functionality, to ensure tha t the class works correctly (relative to its
specification). If the new functionality calls on existing methods, then tests should be performed
to ensure that these methods continue to function correctly. If any existing instance variables are
modified by the new methods, or the methods they call, then the effects of these changes should
be determined. This may result in re-testing the whole class.
Over-riding methods. In these situations, the newly defined methods must of course be tested. This
should test the new definition to ensure that it handles the same range of values as the original
and produces the same results. If this is not what was desired, then over -riding was not the
correct approach.
Next all the methods which invoke the overridden operatio n must be re -tested. This can be
done by using the tools provided with the Smalltalk system to identify all the senders of the
messages associated with the changed methods. This will provide the initial test list. If the
behavior of inherited methods is ch anged in any way then this should be treated as adding
functionality and tested as above.
Super Class references . If the subclass changes anything used by the super class, for example by
referencing a pool variable, then the super class must also be subje cted to incremental testing.
Again, the process needs to identify the elements of the class which have been affected and to
test those elements. In the case of a pool variable, it may also involve testing other classes which
reference the pool variable.
184