At first glance this may seem impossible because it is hard to imagine how you can test one "piece" if the other "pieces" that it uses have not yet been developed (and vice versa). The way around this condundrum is to use stubs and drivers.
Though it is possible to define stubs and drivers at some length, that's not necessary for our purposes here. Instead, we will use the following definitions:
Stub | A piece of code that simulates the activity of missing components. |
Driver | A piece of code that passes test cases to another piece of code. |
We start by "stubbing-out" the UnitConverter
class. This "stubbed-out" class contains comments that
describe the class and all of the methods that we expect it to
have (appropriately commented). All of the non-void
methods return an appropriate default so that the class can
be compiled.
We next write a preliminary driver that can be used to perform
preliminary tests of the UnitConverter
class.
In this version the method calls to the UnitConverter
are all "hard-coded".
Note that these two classes can be compiled and executed.
The next version of the UnitConverter
contains
a complete implementation of the convert
method but
still contains a stub of the getMultiplier
method
(which has been changed slightly to make it more useful).
This enables us to test the convert
method (using the
driver) independently from the other methods.
The next version of the UnitConverter
contains an
implementation (though not a very good one) of the
getMultiplier
method.
To test this version of the UnitConverter
we need to
modify the driver so that it generates more test cases. In this
case we use "white-box (or glass-box) testing" (i.e., we look at the
UnitConverter
class to identify important test cases)
and write a driver that tests all supported inputs.
This process continues until a satisfactory version of the
UnitConverter
is completed.
Copyright 2019