What is Component Testing also called Module Testing in Software Testing:
A component is the lowest unit of any application. So, Component testing; as the name suggests, is a technique of testing the lowest or the smallest unit of any application.
Component testing sometimes is also referred to 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, it is imperial that each 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. It may lead to 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:
- Component Testing
- The objective of Component Testing
- Inputs to Component Level Testing
- Who Does Component Testing?
- What is tested under component Testing?
- When Component Testing is Done?
- Component Testing test strategy
- Stubs and Drivers
- An Example
- How to write component test cases?
- Component Testing Vs Unit Testing
- Component Vs Interface Vs Integration Vs Systems testing
- Recommended Reading
It is a kind of white box testing.
So, component testing looks for bugs and verifies the functioning of the modules/programs which are separately testable.
There is a test strategy and test plan for component testing. And, for each component, there is a test scenario which will be further broken down in test cases. The below diagram represents the same:
The objective of Component Testing
The main objective of component testing is to verify the input/output behavior of the test object. It ensures that the test object’s functionality is working correctly and completely fine as per the desired specification.
Inputs to Component Level Testing
The four major inputs to component level testing are:
- Project Test Plan
- System Requirements
- Component Specifications
- Component Implementations
Who Does Component Testing?
Component Testing is done by QA services or the tester.
What is tested under component Testing?
Component testing may take account of verifying functional or specific non-functional characteristics of system components.
It can be testing resource behavior (e.g. determining memory leaks), performance testing, structural testing, etc.
When Component Testing is Done?
Component Testing is performed after unit testing.
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.
Depending on the development lifecycle model, component testing may be performed in isolation with other components of the system. The isolation is done to prevent external influences.
So, to test that component, we use Stubs and Drivers for simulating the interface between software components.
Integration testing is done after component testing.
Component Testing test strategy
Depending upon the depth of testing level, component testing is divided into two parts:
- Component Testing in Small (CTIS)
- Component Testing in Large (CTIL)
When component testing is done in isolation with other components, it is called as component testing in small. This is done without considering integration with other components.
When component testing is done without isolation with other components of the software then it is called as component testing in large. This happens when there is a dependency on the functionality flow of the components and thus we can’t isolate them.
If the components on which we have dependency are not developed yet, then we use dummy objects in place of the actual components. These dummy objects are the stub (called function) and driver (calling function).
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, 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 Subunit 1
- C4 & C5 together make the Sub Unit 2
- C6, C7 & C8 together make the Sub Unit 3
- C9 alone makes the subunit 4
- Sub Unit 1 and Subunit 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 a 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.
How to write component test cases?
The test cases for component testing are derived from work products, for instance, software design or the data model. Each component is tested through a sequence of test cases where each test case covers a specific combination of input/output i.e. partial functionality.
Below is a sample snip of a component test case for Login Module.
We can write other test cases similarly.
Component Testing Vs Unit Testing
The very first difference between component test and unit testing is that the first one is performed by testers while the second one is performed by testers.
Unit testing is conducted at a granular level. On the other hand, component testing is done at the application level. In unit testing, it is verified if an individual program or the piece of code is getting executed as per the specified. In component testing, each object of the software is tested separately with or without isolation with other components/object of the system.
So, component testing is quite like unit testing, but it is done at a higher level of integration and in the context of the application (not just in the context of that unit/program as in unit testing).
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 the 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 tutorial was useful to understand the Component, Integration, and System testing. If you still have queries, feel free to ask us in comments.