Stubs and Drivers in Software Testing:
Suppose we have two modules in an application named as ‘Module A’ and ‘Module B’. Developers have developed just ‘Module A’. But before finishing ‘Module B’, QA received a requirement to test ‘Module A’. It would not create any problem if ‘Module A’ had no dependency on ‘Module B’. Suppose ‘Module A’ is dependent on ‘Module B’. So what would the testers do? In this case, test ‘Module A’ the developers create a dummy module called Stub to replace ‘Module B’. In another way if ‘Module B’ is dependent on ‘Module A’ but ‘Module A’ is not completed yet and is under development. So here we use Driver to replace ‘Module A’ for testing purposes.
What is a Stub?
In software testing, a stub is a small, simple program or module that serves as a temporary replacement for a part of the system that is not yet available or is still under development. Stubs are used primarily in integration testing when testing a higher-level module that depends on lower-level modules or components that are not ready for testing.
Key characteristics of stubs include:
- Basic Functionality: Stubs typically have minimal functionality, just enough to satisfy the requirements of the module being tested.
- Predefined Responses: Stubs produce predetermined outputs based on the inputs they receive, ensuring consistent and controlled behavior during testing.
- Temporary Nature: Stubs are temporary solutions used during the development and testing phase. Once the actual lower-level components are available, the stubs are replaced with the real implementations.
- Isolation: Stubs allow for the isolation of the module under test from its dependencies, facilitating incremental testing and early identification of issues.
Suppose we have two pages which are to test like the Login page and the Admin page.
You have to test the Login page but the Admin page is still under development. So the flow is like, a login page will call the Admin page after login. But the Admin page is not developed yet. To overcome this type of situation the developers write a dummy program that replaces the Admin
page. This dummy program that is used to replace the Admin page is called Stub.
Stubs are the ‘Called programs’. If it is incomplete, it is replaced with a Stub. (This mainly happens in Top down approach)
What is a Driver?
Like in the earlier example, the Login page is ready but not the Admin page. In this case, assume that the Admin page is developed and ready to test, but the Login page is still under development. To overcome this type of situation, the developers need to write a dummy program that behaves like a Login page. This dummy program is called the Driver. Drivers are ‘Calling programs’. If a ‘Calling program’ is under development, it is replaced with Driver. This happens in the bottom-up approach
Key Characteristics of Driver include
- Purpose: Drivers are used when testing the lower-level modules or components, and the higher-level modules or components they interact with are not yet available or complete.
- Functionality: Drivers are modules that simulate the behavior of the higher-level modules. They generate inputs for the lower-level module under test and provide a way to verify its correctness by receiving outputs.
- Use Cases: Drivers are commonly used in a top-down integration testing approach, where testing progresses from higher-level modules to lower-level modules.
Stubs and drivers are both used to facilitate the testing of modules in isolation when their dependencies are not fully developed. Stubs simulate the behavior of lower-level modules for testing higher-level modules, while drivers simulate the behavior of higher-level modules for testing lower-level modules.
