JMU JMU - Department of Computer Science
Help Tools
Stubs and Drivers

1 Overview

For a variety of different reasons (that we don't have the space to go into here), it is almost always a good idea to develop and test software in "pieces".

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.

2 An Example

We now consider an example in which we need to develop a "calculator" that converts between different units (e.g., feet to inches).

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