What is Component Testing? (with Examples)
By Kalpalatha Devi, Community Contributor - May 4, 2023
Testing plays a vital role in the software development life cycle.
There are several testing methods, types, and different levels of testing. Understand what component testing is, its importance, its different types, and how to perform it with an example.
- What is Component Testing?
- Why is Component Testing necessary?
- Types of Component Testing
- Component testing in small
- Component testing in large
What is Component Testing?
A software application is a combination of multiple components or modules. Testing the individual component of any application is called component testing. In this testing, the functionality and usability of each component are validated separately without integrating it with other components, also called module testing.
Why is Component Testing necessary?
The aim of testing any software is to achieve quality and ensure customer expectations are met.
- Component testing is the way to identify the issues at the module level, so defects are captured at the early stage for each module and hence reduces the efforts of both developers and testers while testing the entire application.
- This testing eliminates the errors at the initial stage and builds confidence at the component level.
- As this testing comes before integration testing, it is useful for the team to identify the issues at the component and integration level individually before testing the entire application by QA.
Types of Component Testing
The concept of component testing can be varied from project to project and organization to organization. It mainly depends on the project’s complexity, the software development methodology used, and the component’s dependency on other components.
Based on the complexity of the application, it is derived mainly in two ways:
- Component testing in small (CTIS)
- Component testing in large (CTIL)
Also Read: Types of Mobile Testing
Component testing in small
Testing is performed on the individual components without any dependency on another component of the application, it is called component testing in small. This testing best fits smaller applications.
There is a web application of practice questions for multiple subjects for different grades for a school. Each subject page is developed and tested individually without any dependency on the other subject pages.
Component testing in large
Component testing is to validate the individual components with the help of other components, which means when the input or output of one component is required for testing the other component, it is called component testing in large.
If any component development is yet to be completed, but there is a dependency to test, then dummy code snippets are placed to proceed with testing, called STUB or DRIVER.
Drivers and Stubs
Let’s dive into the concept of the Drivers and Stubs
Stubs and Drivers will be used in both component testing and Integration testing. These are needed to increase the efficiency of testing.
DRIVER
- A dummy code for mocking the behavior of a missing component is required to invoke the testing of the lower-level component.
- This means the driver acts as a called function to the lower-level module when the calling function is not available.
- A driver is a higher-level module in the list.
STUB
- A dummy code for mocking the behavior of a missing component, which is required for testing the other higher-level component.
- A stub is a lower-level module in the list, Stubs will accept the inputs from the high-level module and return the output.
- In simple terms, There is an application with components A, B, C, and D.
- Component B is output from A and C input for D, which are not yet developed.
- Still, A and D are ready for component testing, so in this case, a stub is created for replicating component B, and a Driver is created for replicating component D.
When is Component testing performed?
In SDLC, during the development phase, developers will do unit testing on that component and release a build to the QA team for testing that particular component alone. The entry criteria for component testing is the unit test completion. Then testers will do rigorous testing and validate the functionality against the requirements and report if any bugs are identified.
Component testing is performed before Integration testing and after unit testing.
- Assume you are working on a project which has website development. Once the website’s pages are developed, the development team will do a unit test and release the build for the testing team to test the components.
- Then testing team will do a test on individual pages of the website and will provide the test results.
- In this case, developing all the web pages is optional before allowing the tester to do the testing.
How is Component testing performed?
QA team will do the component testing once the development and unit testing of the component is completed. Test strategy is vital in this method; the QA team will proceed with testing based on the planned testing methodology.
Irrespective of the testing model, everyday activities performed in component testing are as follows:
- QA lead will develop a test plan and strategy document.
- Testers will develop test scenarios and test cases.
- All the functional and non-functional aspects are tested.
- Issues observed will be reported to the development team.
- If automation testing is in the scope of the test strategy, automation scripts are created for the stable components.
Also Read: Test Plan vs Test Case: Core Differences
Component Testing Example
Assume while testing a banking domain application for XYZ bank. The website will be designed with different pages like Accounts, Cards, Insurance, Investments Offers..etc, based on the services provided by the bank. Login pages are designed based on user levels like personal and business access. So if all the pages are designed as multiple components there after the completion of each component, testing can be done.
Based on customer requirements application is developed for different users, and each page is an independent component, so we test them without the dependency on other components (CTIS).
Assuming the login page is yet to develop, the concept of the driver is applied here to ensure the testing of the accounts page
Similarly, if we have to test the fund transfer page the concept of Stubs is applied to the Addpayee page.
Follow-Up Read: How to Test Banking Apps on Real iOS & Android Devices?
Component Testing VS Unit Testing
Component testing | Unit Testing |
---|---|
Testing of the components individually with or without isolation to ensure the functionality of the requirements. | Testing of the developed code at the program level to ensure design specifications. |
QA team will do the component testing. | The developer’s team will do the unit testing. |
Testing is performed after Unit testing and before Integration testing | Unit testing is performed before component testing |
It is a black box testing method, and the internal structure of the code is unknown to the tester | It is a white box testing method, and the internal structure of the code is known to developers |
Testing is performed after the completion of the total development of the component. | Testing is performed after each development step of the component |
Validation is done based on Test scenarios and functional specifications. | Validation is done based on design specification documents. |
Advantages and Limitations of Component Testing
Advantages
- Component testing helps in identifying the defects at an early stage at the module level.
- It reduces the SDLC timelines and reduces the project cost.
- Provides a more reliable system as the component’s functionality is previously tested.
- Reusability of the components helps to produce the fastest delivery.
- Reusability of Test scenarios and automation test scripts and test environment setup defined for component-level testing can also help in reducing test time by QA.
Limitations
- Control on evaluating the entire application is minimal.
- There is a possibility of incomplete requirements.