Stubs and Drivers

7/27/2019 Stubs and Drivers

1/4

Top down Testing

Top down Testing: In this approach testing is conducted from mainmodule to sub module. if the sub module is not developed atemporary program called STUB is used for simulate the submodule.

Advantages:

- Advantageous if major flaws occur toward the top of the program.- Once the I/O functions are added, representation of test cases iseasier.- Early skeletal Program allows demonstrations .

Disadvantages:- Stub modules must be produced- Stub Modules are often more complicated than they first appear to

be.- Before the I/O functions are added, representation of test cases instubs can be difficult.

Bottom up testing

Bottom up testing: In this approach testing is conducted from submodule to main module, if the main module is not developed a

temporary program called DRIVERS is used to simulate the mainmodule.

Advantages:

- Advantageous if major flaws occur toward the bottom of theprogram.- Test conditions are easier to create.- Observation of test results is easier.

Disadvantages:

- Driver Modules must be produced.- The program as an entity does not exist until the last module isadded.

Stubs and Drivers

It is always a good idea to develop and test software in "pieces". But, it

ITSE 4205 S/W MEASURMENTS AND TESTING AREEJALMAJED 1


2/4

may seem impossible because it is hard to imagine how you can testone "piece" if the other "pieces" that it uses have not yet beendeveloped (and vice versa).

A software application is made up of a number of Units, where

output of one Unit goes as an Input of another Unit. e.g. A SalesOrder Printing program takes a Sales Order as an input, which isactually an output of Sales Order Creation program.

Due to such interfaces, independent testing of a Unit becomesimpossible. But that is what we want to do; we want to test a Unit inisolation! So here we use Stub and Driver.

A Driver is a piece of software that drives (invokes) the Unit beingtested. A driver creates necessary Inputs required for the Unit andthen invokes the Unit.

Driver passes test cases to another piece of code. Test Harness or atest driver is supporting code and data used to provide anenvironment for testing part of a system in isolation. It can be calledas a software module which is used to invoke a module under test andprovide test inputs, control and, monitor execution, and report testresults or most simplistically a line of code that calls a method andpasses that method a value.

For example, if you wanted to move a fighter on the game, the drivercode would be moveFighter(Fighter, LocationX, LocationY);

This driver code would likely be called from the main method. Awhite-box test case would execute this driver line of code and check"fighter.getPosition()" to make sure the player is now on the expectedcell on the board.

A Unit may reference another Unit in its logic. A Stub takes place ofsuch subordinate unit during the Unit Testing.

A Stub is a piece of software that works similar to a unit which isreferenced by the Unit being tested, but it is much simpler that theactual unit. A Stub works as a Stand-in for the subordinate unit and

provides the minimum required behavior for that unit. A Stub is adummy procedure, module or unit that stands in for an unfinishedportion of a system.

Four basic types of Stubs for Top-Down Testing are:

- Display a trace message- Display parameter value(s)



3/4

- Return a value from a table- Return table value selected by parameter

A stub is a computer program which is used as a substitute for thebody of a software module that is or will be defined elsewhere or a

dummy component or object used to simulate the behavior of a realcomponent until that component has been developed.

For example, if the movefighter method has not been written yet, astub such as the one below might be used temporarily which movesany player to position 1.

public void moveFighter(Fighter player, int LocationX, int LocationY)

{fighter.setPosition(1);}

Ultimately, the dummy method would be completed with the properprogram logic. However, developing the stub allows the programmerto call a method in the code being developed, even if the method doesnot yet have the desired behavior.

Programmer needs to create such Drivers and Stubs for carryingout Unit Testing.

Both the Driver and the Stub are kept at a minimum level ofcomplexity, so that they do not induce any errors while testing theUnit in question.

Stubs and drivers are often viewed as throwaway code. However, theydo not have to be thrown away: Stubs can be "filled in" to form theactual method. Drivers can become automated test cases.

Example - For Unit Testing of Sales Order Printing program, aDriver program will have the code which will create Sales Orderrecords using hard coded data and then call Sales Order Printingprogram. Suppose this printing program uses another unit whichcalculates Sales discounts by some complex calculations. Then call tothis unit will be replaced by a Stub, which will simply return fixdiscount data.

THE STEPS OF TOP-DOWN SOFTWARE TESTING

To perform top-down software testing, follow this procedure:

1) Start with the top-level module. Create a test system consisting ofthe



4/4

top module and stubs for all the modules it invokes (those attachedbelow it in the structure chart).Test this system. Do not proceed until all errors have been removed.

2) Next, choose any of the modules invoked by the top module just

tested. To create the next test, begin with the system you created inthe last test. But replace the stub of the chosen module with the realmodule. As well, add in stubs for any modules invoked by the chosenone. Run this test system. If any errors occur, they will be due to thenew module's internal logic or its interface with the module that

invoked it.

3) Choose the next module to test. This may be another moduleinvoked by the top module or a module invoked by the one just testedin step2. (Guidelines for selecting a module when a number of modules arepossible, are discussed below.) Replace the chosen module's stubwith the real thing. Next, add in stubs for any modules invoked by

the chosen one. Test this system.4) Continue incrementally adding and testing modules following the

rule for top-down testing until all modules have been tested.

GUIDELINESIn steps 2 and 3, the software tester could choose from a number ofmodules that satisfy the rules of top-down testing. The followingguidelines should be applied:

A) Test critical modules as soon as possible. A critical module mightbe an unusually complex one, one that incorporates some new

technology, or one that is similarto a module that has caused problems in the past.B) Test I/0 (input/output) modules as soon as possible. The tests will

be difficult torun if I/0 modules are not incorporated early into the test system.The sooner you incorporate input modules, the sooner your test will

be able to handle real records. Likewise, the sooner you incorporateoutput modules, the sooner you will be able to easily observe theeffects of your test. Examples of I/0 modules are ones which readrecords from a file, get input from the user, write information to disk,or print information on reports.


Documents

Stubs and Drivers