In software testing the words stub and drivers are described as a replica of the modules that operate as an alternative to the new or missing modules.
Stubs are mainly used in top-down integration testing; on the other hand, drivers are mainly used in bottom-up integration testing individually and designed to enhance the testing process.
To sustain the essential requirements of the inaccessible modules or components, we are precisely established the stubs and drives. And extremely beneficial in getting the anticipated outcomes. Both Stubs and drivers are the essential part of the basic software development and software testing process.
Stubs:
- A stub is a replica of a module that collects the data and develops many possible data. However, it executes like an actual module and is mainly used to test modules.
- Generally, stubs are created by software developers in order to use them instead of modules if the particular modules are miss or not yet developed.
- By using these test stubs, the test engineers can simulate the performance of the lower-level modules, which are not yet joined with the software. Furthermore, it helps us to accelerate the activity of the missing modules.
Types of Stubs :
In the top-down approach of incremental integration testing, the stubs are divided into four essential parts, which are as follows:
- Demonstrate the trace message.
- Exhibits the parameter values.
- Returns the consistent values, which are handled by the modules or the components.
- Returns the values of the specific parameters, which were utilized by testing components or modules.
Drivers
- The Drivers establish the test environments and takes care of the communication, estimates results, and also sends the reports.
- These are just like stubs and used by software test engineers in order to accomplish the missing or incomplete modules/ components requirements.
- The drivers are mainly developed in the Bottom-up approach of incremental integration testing.
- Generally, drivers are bit complex as compared to the stubs.
- These can test the lower levels of the code when the upper-level modules or codes are not developed or missing.
- In other words, we can say that the Drivers perform as pseudo-codes, which are mainly used when the stub modules are completed; however, the initial modules/components are not prepared.