This article discusses the basics of component testing and the importance of using the technique to minimize the overall cost and time of testing.
A component is an individual element of any application that can be integrated with others to form an application as a whole. Component testing is a method of validating the single component before testing the whole application. The reason is that if the individual components are thoroughly tested, then it is less likely that significant defects will appear in the later phases. The applications developed today are generally complex, and it is a real challenge to cover all aspects during testing, which causes a gap in the test coverage. Therefore, component testing is executed before moving into higher levels of testing.
Component Testing Objectives
The primary objective of component testing is to validate the behavior of the individual component, as specified in the requirements document. The tester isolates an individual from other parts to prevent external influence and ensure that efficient results are generated. It is important to note that some of the components may depend on others, which have not yet been developed. For that purpose, we use Stubs and Drivers to verify our results.
Understanding Stubs and Drivers
It is essential to understand the concept and function of Stubs and Drivers in component testing.
Whenever component testing is executed in complete isolation, or without integrating with other components, we call it Component Testing in Small. However, if any element is dependent on another element or we are unable to isolate the individual component, then this process is called Component Testing in Large.
As described in the previous section, if any component has a dependency on any other component which has not yet been developed, then we temporarily use dummy objects to compensate. These are known as Stubs and Drivers, which, for the purpose of testing, behave as the interface between components.
Let’s understand the concept further. The development team has deployed component A of an application in the testing environment, but there are two more components (B and C) that are yet to be developed. As the tester progresses into the testing, he realizes that a few of the functionalities of component A is dependent on the remaining components, and it is not possible to thoroughly test that particular component in isolation. For that purpose, Stubs and Drivers need to act as substitutes, instead of waiting for the application to be completed.
Stubs: These are dummy programs, also known as called programs, which are used primarily when sub-programs or components are still under construction.
Drivers: These are also dummy programs and are known as calling programs, and are primarily used when main programs or components are still under construction.
An Example
We have an application with three components named as Login, Home, and User. The Login component is deployed in the testing environment, but other components (Home and User), which need to be called by the Login, are yet to be completed. For testing, the developer will add a piece of code that simulates the call methods of the remaining components. This particular piece of code will be called Stub and is a top-down approach.
If Home and User components are ready, but Login component is yet to be developed, from where both components get their return values, then the developer will add a piece of code that simulates the Login component. This particular piece of code will be called a Driver and is a bottom-up approach.
Component Testing VS Unit Testing
The purpose of component testing is to test individual components, with or without isolation and is performed by a tester who validates against test requirements. However, Unit Testing is performed by the developer within their environment where each program is tested to check whether it executes according to the specification.
Conclusion
Component testing plays a crucial part in laying a foundation for testing activities, and if performed thoroughly, there will be fewer defects to identify in the later phases. This does not mean that no issue will arise at that stage, but their nature will be different due to configuration and integration.
