Since unit is the smallest building block of the software system, it is the first piece of system to be validated. Before we validate the entire software, units or modules must be validated. Unit testing is normally considered an adjunct to the coding step. However, it has been discussed that testing with the code of a unit is called the verification step. Units must also be validated to ensure that every unit of software has been built in the right manner in conformance with user requirements. Unit tests ensure that the software meets at least a baseline level of functionality prior to integration and system testing. While developing the software, if the developer detects and removes the bug, it offers significant savings of time and costs. This type of testing is largely based on black-box techniques.

Though software is divided into modules, a module is not an isolated entity. The module under consideration might be getting some inputs from another module or the module is calling some other module. It means that a module is not independent and cannot be tested in isolation. While testing the module, all its interfaces must be simulated if the interfaced modules are not ready at the time of testing the module under consideration. The types of interface modules which must be simulated, if required to test a module are discussed next.

Drivers

Suppose a module is to be tested, wherein some inputs are to be received from another module and this module which passes inputs to the module to be tested is not ready and under development. In such a situation, we need to simulate the inputs required in the module to be tested. For this purpose, a main program is prepared, wherein the required inputs are either hard-coded or entered by the user and passed on to the module under test. This module where the required inputs for the module under test are simulated for the purpose of module or unit testing is known as a driver module. The driver module may print or interpret the results produced by the 'module under testing.

For example, see the design hierarchy of the modules, as shown in Fig.1. Suppose module, $\mathrm{B}$ is under test. In the hierarchy, module $\mathrm{A}$ is a super-ordinate of module B. Suppose module $\mathrm{A}$ is not ready and $\mathrm{B}$ has to be unit tested. In this case, module $\mathrm{B}$ needs inputs from module A. Therefore, a driver module is needed, which will simulate module A in the sense that it passes the required inputs to module B and acts as a main program for module B in which its being called, as shown in Fig. 2.

Therefore, it can be said that a test driver is supporting the code and data used to provide an environment for testing a part of a system in isolation. In fact, it drives the unit being tested by creating necessary inputs' required. for the unit and then invokes the unit. A test driver may take inputs in the following form and call the unit to be tested:

• It may hard-code the inputs as parameters of the calling unit.
• It may take the inputs from the user.
• It may read the inputs from a file.

Thus, a driver can be defined as a software module, which is used to invoke a module under test and provide test inputs, control and monitor execution, and report test results or most simplistically a line of code that calls a method and passes a value to that method.

A test driver provides the following facilities to a unit to be tested:

• Initializes the environment desired for testing
• Provides simulated inputs in the required format to the units to be tested.

Projects where commercial drivers are not available, specialized drivers need to be developed. This happens mainly in defence projects where projects are developed for a special application.

Stubs

The module under testing may also call some other module, which is not ready at the time of testing. Therefore, these modules need to be simulated for testing. In most cases, dummy modules instead of actual modules, which are not ready, are prepared for these subordinate modules. These dummy modules are called stubs.

Thus, a stub can be defined as a piece of software that works similar to a unit which is referenced by the unit being tested, but it is much simpler than the actual unit. A stub works as a 'stand-in' for the subordinate unit and provides the minimum required behaviour for that unit.

For example, consider Fig. 1 again. Module B under test needs to call module D and module E. However, they are not ready and there must be some skeletal structure in their place so that they act as dummy modules in place of the actual modules. Therefore, stubs are designed for module D and module E, as shown in Fig.3.

Stubs have the following characteristics:

• Stub is a place holder for the actual module to be called.
• Therefore, it is not designed with the functionalities performed by the actual module. It is a reduced implementation of the actual module.
• It does not perform any action of its own and returns to the calling unit (which is being tested).
• We may include a display instruction as a trace message in the body of stub. The idea is that the module to be called is working fine by accepting the input parameters.
• A constant or null must be returned from the body of stub to the calling module.
• Stub may simulate exceptions or abnormal conditions, if required.

Benefits of Designing Stubs and Drivers

The benefit of designing drivers and stubs (see Fig. 4) is that a unit will work/behave in the simulated environment as in the actual software environment. Now a unit test can be written against the interface and the unit will still work properly once the drivers and stubs have been placed correctly.

The benefits of designing subs and divers are:

• Stubs allow the programmer to call a method in the code being developed, even if the method dos not he desired behavior yet.
• By using stubs and drivers effectively, we can cut down out total debugging and testing time by testing small parts of a program individually, helping us to narrow down problems before the expand.
• Stubs and drivers can also be an effective tool for demonstrating progress in a business environment. For example, if, you are implement four specific methods in a class by the end of the week, for an insert subs for any method and write a short driver program so that you can demonstrate to your manager or client the the requirement has been met. As you continue, you can replace the stubs and drivers with the real code to finish your program.

However, drivers and stubs represent overheads also. Overheads involved in of designing them may increase the time and cost of the entire software system. Therefore, they must be designed simple to keep overheads low. Stubs and drivers are generally prepared by the developer of the module under testing. Developers use them at the time of unit verification. However, they can also be used by any other person who is validating the unit.