One of the most important concepts while doing software testing, particularly during integration testing is the concept of stubs and drivers. Many are confused on this topic, because both of them seem to be the same thing. However they are not. It is important to understand the difference between both of them.
So while doing integration testing, many of us are faced with the scenario, when one module is still not ready for testing, which means that the development work is still going on the module. It may be a major module or a minor module to a major module. Now when you are assigned to test modules which are dependent on such modules, which are incomplete, then we have a catch. How do we test the modules, which are not still ready for test, or how do we get the input or output from that module.
So in order to minimize that, we have the concept of the stubs and drivers. Most of us have heard of the two approaches in software testing – the top down approach, where the major modules are first configured and coded and then sub modules are done, and the second, bottom up approach, where the minor modules are first configured and then the major modules.
Stubs and Drivers are two types of Test Harness. Test harness are the collection of software and test data which is configured so that we can test a program unit by simulating different set of conditions, while monitoring the behavior and outputs.
Stubs and drivers both are dummy modules and are only created for test purposes.
Stubs are used in top down testing approach, when you have the major module ready to test, but the sub modules are still not ready yet. So in a simple language stubs are “called” programs, which are called in to test the major module’s functionality.
For eg. suppose you have three different modules : Login, Home, User. Suppose login module is ready for test, but the two minor modules Home and User, which are called by Login module are not ready yet for testing.
At this time, we write a piece of dummy code, which simulates the called methods of Home and User. These dummy pieces of code are the stubs.
On the other hand, Drivers are the ones, which are the “calling” programs. Drivers are used in bottom up testing approach. Drivers are dummy code, which is used when the sub modules are ready but the main module is still not ready.
Taking the same example as above.Suppose this time, the User and Home modules are ready, but the Login module is not ready to test. Now since Home and User return values from Login module, so we write a dummy piece of code, which simulates the Login module. This dummy code is then called Driver.
QATechnicals 