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.
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.
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.
There are basically four types of stubs used in top-down approach of integration testing, which are mentioned below:
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.
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.
The 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 the module-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.
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:
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.
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.
|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.|
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.