A driver can be defined as a piece of code so that it becomes easier to call other programs or code modules. Drivers are identified as the main program, which is used to call other modules. When anyone decides to test any module, it is important that we should have a main program that calls the test module. Without any sample of program, the testing of module is impossible.
In software testing, the test drivers are used in bottom-up integration testing to functionally simulate the behaviour of upper level modules, which are not simulated yet. These drivers are a set of modules that acts as a temporary replacement for the next calling module and supplies the same output. The test drivers are required when there is a necessity for the interaction with an external system. Usually test drivers are bit complex than stubs.
Let’s consider a student information management application, where we have 4 modules as stated below along with their description:
Module-A: Login Page
Module-B: Home Page
Module-C: Print Setup Page
Module-D: Logout Page
All these module are interdependent on each other. For example, to reach home page(Module-B), you need to first validate the login page(Module-A). Similarly, to test Print Setup Page(Module-C), you need to execute or access and validate Home Page(Module-B) Further, in order to test logout page(Module-D) you first need to execute Login page(Module-A), thereafter which you can test the logout page.
Thus, it may be inferred that to test the whole application/system, availability of each module is a must requirement and in the absence of any of these module (may be modules is/are yet to be created or is/are currently not available), it will not be feasible to carry out the testing of the complete application. In such events, drivers may be used, which fills the deficiency of missing/non-available modules.
.png)
.png)
Advertisement:
