What is Component/Module Testing? – with Example

We have given a detailed explanation of component testing, also known as module testing, with examples in this article.

What is Component Testing that is also called Module Testing in Software Testing?

The component is the lowest unit of any application. Component testing, as the name suggests, is a technique of testing the lowest or the smallest unit of any application.

Component testing is sometimes also referred to as Program or Module Testing.

An application can be thought of as 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 and 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.

Component Testing

The software applications are huge in nature and it is a challenge to test the entire system. This may lead to many gaps in 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

Component Testing

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. Also, for each component, there is a test scenario which will be further broken down in test cases. The below diagram represents the same:

Objectives of Component Testing

The main objective of component testing is to verify the input/output behavior of the test object. This ensures that the test object’s functionality is working correctly and completely fine as per the desired specification.

Inputs for Component Level Testing

The four major inputs for 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 into account 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 Is Component Testing Done

Component Testing is performed after unit testing.

Components are tested as soon as they are created, so there is a chance 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. 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:

1. Component Testing in Small (CTIS)
2. Component Testing in Large (CTIL)

When component testing is done in isolation with other components, it is called 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 get into a brief about Stubs and Drivers, I should tell you about the difference between Component tests and Integration tests. 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 a single component/module is tested thoroughly before integrating it to other components. Component testing is performed before Integration testing.

Both Integration and Components use 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.

We see that here:

• 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 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 will be doing:

• COMPONENT testing for C1 to C9
• INTEGRATION testing between Sub Units and Business Units
• SYSTEM testing of the Application as a whole

An Example

Up till now, we must have seen that Component testing is some kind of a white box testing technique. Well, that 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 cannot 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 has been 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 in time would be:

• UI is tested for usability (spelling mistakes, logos, alignment, formatting etc.)
• Try using negative testing techniques like 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.

Since 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 effectively

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 in a similar way.

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 developers or SDET professionals.

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 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/objects 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 have explained earlier, 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 Interface testing is done, come Integration testing.

During the Integration test, we combine the individual tested components one by one and then test it incrementally. We validated during Integration that the individual components when combined one by one, do 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 Systems testing to test the entire application/system as a whole. This test validates the business requirements against the implemented software.

Conclusion

I would say that Unit testing and Component testing are done side by side.

However, 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 thorough Component testing done before kicking off the Integration testing.

If Component testing is performed well, we will find fewer defects in the integration testing. There could be issues, but those issues could be related to the integration environment or configuration challenges. Please 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 the comments. We would love to hear from you.