What is meant by Stubs and Drivers?

Feb 12, 2020

Stubs and Drivers: Introduction

In software testing life cycle, there are numerous components that play a prominent part in making the process of testing accurate and hassle free. Every element related to testing strives to improve its quality and helps deliver accurate and expected results and services that are in compliance with the defined specifications. Stubs and drivers are two such elements used in software testing process, which act as a temporary replacement for a module. These are an integral part of software testing process as well as general software development. Therefore, to help you understand the significance of stubs and drivers in software testing, here is elaborated discussion on the same.

What is meant by Stubs and Drivers?

In the field of software testing, the term stubs and drivers refers to the replica of the modules, which acts as a substitute to the undeveloped or missing module. The stubs and drives are specifically developed to meet the necessary requirements of the unavailable modules and are immensely useful in getting expected results.

Stubs and drivers are two types of test harness, which is a collection of software and test that is configured together in order to test a unit of a program by stimulating variety of conditions while constantly monitoring its outputs and behaviour. Stubs and drivers are used in top-down integration and bottom-up integration testing respectively and are created mainly for the testing purpose.

Defining Stubs:

Stubs are used to test modules and are created by the team of testers during the process of Top-Down Integration Testing. With the assistance of these test stubs testers are capable of stimulating the behaviour of the lower level modules that are not yet integrated with the software. Moreover, it helps stimulates the activity of the missing components.

Types of Stubs:

There are basically four types of stubs used in top-down approach of integration testing, which are mentioned below:

Displays the trace message.
Values of parameter is displayed.
Returns the values that are used by the modules.
Returns the values selected by the parameters that were used by modules being tested.

Defining Drivers:

Drivers, like stubs, are used by software testers to fulfil the requirements of missing or incomplete components and modules. These are usually complex than stubs and are developed during Bottom-Up approach of Integration Testing. Drivers can be utilized to test the lower levels of the code, when the upper level of codes or modules are not developed. Drivers act as pseudo codes that are mainly used when the stub modules are ready, but the primary modules are not ready.

Stubs and Drivers: Example

Consider an example of a web application, which consists of 4 modules i.e., Module-A, Module-B, Module-C and Module-D. Each of the following modules is responsible for some specific activity or functionality, as under:

Consider an example of a web application, which consists of 4 modules i.e., Module-A, Module-B, Module-C and Module-D. Each of the following modules is responsible for some specific activity or functionality, as under

Module-A ? Login page of the web application.

Module-B → Home page of the web application.

Module-C → Print Setup.

Module-D → Log out page.

modules A, B, C & D involves the interdependencies of each module over other.

It is always preferable, to perform testing, in parallel, to the development process. Thus, it implies that subsequent testing must be carried out, immediately after the development of the each module.

Module-A will be tested, as soon as, it develops. However, to carry out and validate the testing procedures in respect of module-A, there urges the need of Module-B, which is not yet developed. The expected functionality of the login page (module-A) could be validated, only if it is directed to the home page (Module-B), based on the valid and correct inputs.

But, on the non-availability of theModule-B, it will not be possible to test module-A. These types of circumstances, introduces the stubs & drivers in the process of software testing. A dummy module, representing the basic functionality or feature of the module-B, is being developed, and thereafter, it is being integrated with the module-A, to perform testing, efficiently.

Similarly, stubs and drivers, are used to fulfil the requirements of other modules, such as

Log out page (Module-D), needs to be directed to the login page (Module-A), after successfully logging out from the application. In the event of unavailability of Module-A, stubs and drivers will work as a substitute for it, in order to carry out the testing of module-D.

Why are Stubs & Drivers Required?

Though, the important of stubs and drivers is immense during software testing, but its relevance as well as the requirement ends once the equivalent module is created. As they act as a temporary replacement of modules, these role in testing culminates once final output is generated. Therefore, these pseudo modules or stubs and drivers are mainly used for following reasons:

Commonly used in porting, distributed computing, as well as general software development.
Used for meeting necessary requirements unavailable modules.
They are required when the system needs to interact with external systems.
Stubs and drivers are used to test modules.
Stubs are used to test the functionality of modules, whereas drivers are used when the main module is not ready.

Are Stubs and Drivers, Same?

Yes, basically the features and purpose of stubs and drivers are same. Both of them work as a substitute for the missing or unavailable module. However, the difference between them can be visualized during the integration testing.

Stubs are commonly referred to as "called programs" and are being used in top bottom approach of the integration testing, whereas drivers are "calling program" and they are used in bottom-up integration testing.
Stubs are similar to the components, which are under test, in a very simple and basic form, whereas driver is used to invoke the component that needs to be tested.
Stubs, are usually, considered for low level modules, whereas drivers represents the high level modules.

Key Points: Stubs and Drivers

Stubs and Drivers works as a substitute for the missing or unavailable module.
They are specifically developed, for each module, having different functionalities.
Generally, developers and unit testers are involved in the development of stubs and drivers.
Although, it provides ease to carry out of individual components, without concerning the availability of other modules, but it is a time-consuming process, as it requires to develop dummy for each missing module.
Their most common use may be seen in the integration incremental testing, where stubs are used in top bottom approach and drivers in a bottom up approach.

Comparison of Stubs & Drivers:

Even though both stubs and drivers are dummy/pseudo codes, there are various features of these two components that are different from each other. Therefore, to signify their differences, here is a comparison of stubs and drivers.

Stubs	Drivers
1. Used in Top-Down Integration Testing.	1.Used in Bottom-Up Integration Testing.
2. A piece of code that emulates the called function.	2. A piece of code that emulates a calling function.
3. Stubs stimulates the activity of missing and not developed modules.	3. Drivers pass test cases to another code and invoke modules under testing.
4. These are created when high level modules are tested and lower level modules are not developed.	4. These are created when lower level modules are tested and higher level modules are not yet developed.

Conclusion:

The process of software testing cannot be completed with incomplete components and modules. Therefore, to ensure the accuracy as well as effectiveness of testing it is vital to create stubs and drivers that fulfil the requirements of incomplete or undeveloped modules and act as pseudo modules or codes that are called in for testing the functionality of major modules. In short, there is no doubt that stubs and drivers are an integral part of software testing process.