They are computer programs which act as a substitute for some other modules (which are not available for testing). These computer programs will simulate the functionalities of the other modules thereby facilitating the software testing activity.

What are stubs?

Stubs are basically used in a TOP-DOWN approach of integration testing. In this approach, the upper modules are prepared first and are ready for testing while the bottom modules are not yet prepared by the developers.

So in order to form the complete application, we create dummy programs for the lower modules in the application so that all the functionalities can be tested.

Four basic types of stubs are as follow:

1. Display a trace message which is used by the modules being tested
2. Display the parameter values which are used by the modules
3. Return the values which are used by the modules
4. Return values selected by the parameter which are used by the modules being tested.

Example of stub

Suppose if we have an application in which there are three modules, say Login, Add student and Cancel Admission. Now suppose we are doing unit testing of the module Login and the modules Add Student and Cancel Admission are yet not prepared. Then we will create dummy modules for Add student and Cancel admission in order to carry out testing of Login modules. These dummy modules of Add student and Cancel admission are known as stubs. They receive instructions from the login module and display the success or failure of login functionality.

What are the drivers?

A driver is basically a piece of code through which other programs or pieces of code or modules can be called. Drivers are the main program through which other modules are called.

If we want to test any module it is required that we should have a main program which will call the testing module. Without the dummy program or driver, the complete testing of the module is not possible.

Drivers are basically called in BOTTOM UP testing approach. In a bottom-up testing approach the bottom level modules are prepared but the top level modules are not prepared. Testing of the bottom level modules is not possible with the help of the main program. So we prepare a dummy program or driver to call the bottom level modules and perform its testing.

Example of the driver

Suppose we have an application in which three modules are there, say Login, Add student and Cancel Admission. Now we want to do the testing of the Add student module.

Add student module cannot run standalone; first, we have to enter into login page and then add student module will be executed. So Add Student module will be called by the Login module. Let us assume that the Login module has not been developed by the developers. In this case, we have to create a dummy module of Login which will call the Login module and then the functionalities of the add student module will be tested. In this case, the Login module will be called as a driver and the add student will be the module which is being tested.

What is the difference between stubs and drivers in software testing?

Stub

1. Stubs are created in the integration testing that is following a Top-down approach.
2. A stub is a piece of code emulating a called function. A stub is created by the tester when high-level modules are being tested and the other modules are not yet created. Overall testing is only possible when all the modules are present and dummy modules have to be created to replicate basic functionality of modules under construction.
3. A stub is basically a piece of code that simulates the activity of missing modules. I just accept the value from the calling module and returns a null value.

Driver

1. A driver is a piece of code which is emulating a calling function. Basically, we call the driver as the main function which calls other modules to form complete applications.
2. Drivers are created in integration testing following a bottom-up approach. Dummy main function has been created which will call other submodules.
3. A piece of code that passes test cases to another piece of code. Drivers invoke modules under testing.

One simple way to remember the difference in stubs and drivers is to remember drivers are “calling” function while stubs are “called” functions.