A component is the lowest unit of any application. So Component testing; as the name suggest, is a technique of testing the lowest or the smallest unit of any application.
Component testing sometimes is also referred as Program or Module Testing.
An application can be thought of a combination and integration of many small individual modules. Before we test the entire system as a whole, it is imperial that each and every component OR the smallest unit of the application is tested thoroughly.
In this case, the modules or the units are tested independently. Each module receives an input, does some processing and generates the output. The output is then validated against the expected feature.
The software applications are huge in nature and it is a challenge to test the entire system as a whole. It may lead into many gaps in the test coverage. Hence before moving into Integration testing or functional testing, it is recommended to start with Component testing.
Also read => Unit, Integration and Functional Testing difference
What You Will Learn:
Some more Insights:
Components are tested as soon as they are created, so there are chances that the results retrieved from a component under test, are dependent on other components which in turn are not developed as of now. So in order to test that component, we use Stubs and Drivers.
Before I jump to brief about Stubs and Drivers, I should brief about the difference between Component tests and Integration tests. The reason is – Stubs and drivers are also used in Integration testing so this may lead to some confusion between these two testing techniques.
Integration testing technique is a technique where we combine 2 components sequentially and test the integrated system together. Data from one system is traversed to another system and the correctness of data is validated for the integrated system.
Unlike module testing where the single component/module is tested thoroughly before integrating it to other components. So we can say that Component testing is performed before Integration testing.
Both Integration and Component uses Stubs and Drivers.
“Drivers” are the dummy programs which are used to call the functions of the lowest module in case the calling function does not exist.
“Stubs” can be referred to as code a snippet which accepts the inputs/requests from the top module and returns the results/ response
As explained earlier, the components are tested individually and independently. So there may be some features of the components, dependent on the other component which is not developed currently. So in order to test the components with these “undeveloped” features, we have to use some stimulating agents which would process the data and return it to the calling components.
This way we are making sure that the individual components are tested thoroughly.
Here we see that:
- C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— are the components
- C1, C2 and C3 together make the Sub unit 1
- C4 & C5 together make the Sub Unit 2
- C6, C7 & C8 together make the Sub Unit 3
- C9 alone makes the sub unit 4
- Sub Unit 1 and Sub unit 2 combine to make Business Unit 1
- Sub Unit 3 and Sub Unit 4 combine to make Business Unit 2
- Business Unit 1 and Business Unit 2 combine to make the application.
- So the Component testing in this case would be to test the individual components which are C1 to C9.
- The Red arrow between the Sub Unit 1 and Sub Unit 2 shows the Integration testing point.
- Similarly, the Red arrow between Sub Unit 3 and Sub Unit 4 shows the Integration testing point
- The Green arrow between Business Unit 1 and Business Unit 2 shows the integration testing point
Hence we would be doing:
- COMPONENT testing for C1 to C9
- INTEGRATION testing between the Sub Units and Business Units
- SYSTEM testing of the Application as a whole
Up till now, we must have established that Component testing is some kind of a white box testing technique. Well, it may be right. But this does not mean that this technique could not be used in Black box testing technique.
Consider a huge web application which starts with a Login page. As a tester (that too in an agile world) we could not wait till the entire application is developed and is made ready to test. In order to increase our time to market, we must start testing early. So when we see that the Login page is developed, we must insist that it is made available for us to test.
As soon as you have the Login page available for you to test, you can execute all your test cases, (positive and negative) to ensure that the Login page functionality is working as expected.
The advantages of testing your login page at this point of time would be:
- UI is tested for usability (spelling mistakes, logos, alignment, formatting etc.)
- Try to use negative testing techniques like of authentication and authorization. There is a huge probability of finding defects in these cases.
- Use of techniques like SQL Injections would ensure to test the breach of security at a very early stage.
The defects which you would log at this stage would act as “lessons learned” for the development team and these would be implemented into the coding of the consecutive page. Hence by testing early – you have ensured better quality of the pages which are yet to be developed.
Because the other consecutive pages are not yet developed, you may need stubs to validate the login page functionality. For example, you may want a simple page stating “logging successful”, in case of correct credentials and error message popup window in case of incorrect credentials.
You can go through our earlier tutorial on Integration testing to have more insights on Stubs and Drivers.
Component Vs Interface Vs Integration Vs Systems testing:
Component, as I explained, is the lowest unit of an application which is tested independently.
An interface is the joining layer of the 2 components. Testing of the platform or the interface on which the 2 components interact is called Interface testing.
Now, testing the interface is a bit different. These interfaces are mostly API’s or Web Services, so testing of these interfaces would not be similar to Black Box technique, rather you would be doing some kind of API testing or Web Service testing using SOAP UI or any other tool.
Once the Interface testing is done, comes the Integration testing.
During Integration test, we combine the individual tested components one by one and test it incrementally. We validate during Integration that the individual components when combined one by one, does behave as expected and the data is not altered when flowing from 1 module to another module.
Once all the components are integrated and tested, we perform the Systems testing to test the entire application/system as a whole. This test validates the business requirements against the implemented software.
I would say that Unit testing and Component testing are done side by side.
Unlike Unit testing which is done by the development team, Component/module testing is done by the Testing team. It is always recommended to have a through Component testing done before kicking off the Integration testing.
If the Component testing is rock solid, we will find fewer defects in the integration testing. There would be issues, but those issues would be related to the integration environment or configuration challenges. You can ensure the functionality of the components integrated is working fine.
Hope this article is useful to understand the Component, Integration, and System testing. If you still have queries feel free to ask us in comments.