What is Component Testing Or Module Testing (Learn With Examples)

A deeper look into Component Testing aka Module Testing in Software Testing:

In the context of any application, a component is the smallest unit. Component testing therefore, as suggested by its name, involves testing the smallest or most minute units of an application.

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

You can view an application as an amalgamation and blend of many smaller, individual modules. Prior to testing the overall system, it’s critical to ensure each component OR the smallest unit of the application has been tested thoroughly.

In this scenario, the modules or units are tested in isolation. Each module takes in input, processes it, and generates output. This output is then checked against the expected functionality.

Software applications have a wide scope and testing the whole system is a challenging task. This might cause gaps in test coverage. Therefore, it’s advised to begin with Component testing before moving into Integration testing or functional testing.

Don’t forget to check out => The differences between Unit, Integration, and Functional Testing

Component Testing

This is a form of white box testing.

Thus, component testing aims to identify bugs and confirm the operationality of the modules/programs that can be tested independently.

A test approach and test plan exist for component testing. Moreover, each component has a test scenario that will be further divided into test cases. The following diagram illustrates this:

The goal of Component Testing

The primary aim of component testing is the validation of the test object’s input/output behavior. It ensures the functionality of the test object operates correctly and fully according to the intended specification.

Inputs to Component Level Testing

The four major inputs needed for component level testing include:

• Project Test Plan
• System Requirements
• Component Specifications
• Component Implementations

Who conducts Component Testing?

Component Testing is completed by QA services or the tester.

What is evaluated under Component Testing?

Component testing might encompass verification of functional or particular non-functional attributes of system components.

It might involve testing resource behavior (like identifying memory leaks), performance testing, structural testing, and so on.

When is Component Testing conducted?

Component Testing is undertaken subsequent to unit testing.

Components are tested as soon as they are produced. Therefore, the results fetched from a component under evaluation might be reliant on other components that are still under development.

Depending upon the development lifecycle model, component testing might be executed separately from the system’s other components. This isolation is done to inhibit external influences.

To test that component, we employ Stubs and Drivers to simulate the interface between software components.

Component testing is conducted prior to integration testing.

Component Testing test strategy

Based on the depth of the level of testing, component testing is categorized into two sections:

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

When component testing is conducted separately from other components, it’s called component testing in small. This is done without considering integration with other components.

When component testing is conducted in conjunction with other software components without isolation, it is referred to as component testing in large. This occurs when there is a dependency on the functionality flow of the components, which subsequently prevents us from isolating them.

If the components that we are dependent on are not yet developed, we utilize dummy objects in place of the actual components. These dummy objects could be the stub (called function) and driver (calling function).

Stubs and Drivers

Before delving into Stubs and Drivers, I should outline the difference between Component tests and Integration tests. This is because Stubs and drivers are also employed in Integration testing, which might create some ambiguity between these two testing methods.

Integration testing is a method where we sequentially merge 2 components and test the integrated system in unison. Data is transferred from one system to another and the data accuracy is validated for the integrated system.

Contrarily, module testing ensures the single component/module is comprehensively tested before integrating it with other components. Thus, we can state that Component testing is conducted prior to Integration testing.

Both Integration and Component use Stubs and Drivers.

“Drivers” are the mock programs used to call the functions of the lowest module in cases where the calling function does not exist.

“Stubs” denote code snippets that accept the inputs/requests from the top module and return the results/response.

As previously explained, components are tested individually and independently. Thus, certain features of the components might be reliant on another component that is not currently developed. Therefore, to test the components with these “undeveloped” features, we employ some stimulants that would process the data and return it to the calling components.

This procedure ensures the individual components are tested thoroughly.

Here we observe that:

• C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— represent components
• The combination of C1, C2, and C3 forms Subunit 1
• The conjunction of C4 & C5 forms Subunit 2
• The combination of C6, C7 & C8 forms Subunit 3
• C9 alone forms Subunit 4
• Subunit 1 and Subunit 2 combine to form Business Unit 1
• Subunit 3 and Subunit 4 combine to create Business Unit 2
• Business Unit 1 and Business Unit 2 combine to create the application.
• Therefore, in this scenario, Component testing would involve testing the individual components, which are C1 to C9.
• The Red arrow between Subunit 1 and Subunit 2 indicates the Integration testing point.
• Similarly, the Red arrow between Subunit 3 and Subunit 4 indicates the Integration testing point
• The Green arrow between Business Unit 1 and Business Unit 2 depicts the integration testing point

Therefore, we would be executing:

• COMPONENT testing for C1 to C9
• INTEGRATION testing between Subunits and Business Units
• SYSTEM testing of the entire Application

An Example

Up to this point, we have established that Component testing is a type of white box testing technique. While this is true, it doesn’t necessarily mean this technique cannot be applied in black box testing procedures.

Consider a vast web application beginning with a Login page. As a tester (especially in the agile environment), we cannot sit idle until the entire application is developed and ready for testing. In order to expedite our time to market, we must initiate testing as early as possible. Therefore, when we notice that the Login page is developed, we must request it to be available for testing.

The moment you have the Login page accessible for testing, you can carry out all your test cases (positive and negative) to verify that the Login page functionality is working as anticipated.

The merits of testing your login page at this stage include:

• User Interface is tested for usability (spelling errors, logos, formatting, alignment, and so on).
• Attempt utilizing negative testing methods such as authentication and authorization. There’s a high likelihood of discerning defects in these scenarios.
• Employ techniques such as SQL Injections to examine for security breaches at an early stage.

The defects you log at this phase would serve as “lessons learned” for the development team and these would be incorporated into the coding of the succeeding page. By testing earlier, you have assured better quality for the pages that are yet to be developed.

Given the other consecutive pages are not yet developed, you may require stubs to validate the login page functionality. For example, you may need a simple page stating “login successful” in case of correct credentials and an error message pop-up window in case of incorrect credentials.

You can refer to our previous tutorial on Integration testing for a deeper understanding of Stubs and Drivers.

How to draft component test cases?

The test cases for component testing are derived from work items such as software design or the data model. Each component is tested with a sequence of test cases, with each test case covering a particular combination of input/output, or partial functionality.

Below is a sample snippet of a component test case for the Login Module.

Other test cases can be written in a similar manner.

Component Testing Vs Unit Testing

The main distinction between component testing and unit testing is that component testing is executed by testers whereas unit testing is conducted by developers or SDET professionals.

Unit testing is performed at a detailed level. Conversely, component testing is executed at the application level. In unit testing, it is ensured if a single program or piece of code is functioning as stated. In component testing, each object of the software is tested separately, with or without segregation from other components/objects of the system.

Therefore, component testing is indeed similar to unit testing but it is done at a broader level of integration and within the context of the application (and not just within the context of that unit/program as in unit testing).

Component Vs Interface Vs Integration Vs Systems testing

A Component, as previously defined, is an application’s smallest unit that is tested independently.

An interface is the connecting layer of two components. Testing the platform or interface where two components interact is termed Interface testing.

Interface testing is slightly different. These interfaces are commonly APIs or Web Services, therefore, testing these interfaces would not resemble Black Box techniques; instead, you would be conducting some form of API testing or Web Service testing using SOAP UI or other available tools.

Once the Interface testing is complete, Integration testing commences.

During Integration testing, we incrementally merge the individually tested components one by one and test them. We verify during Integration that the individual components, when sequentially combined, operate as expected and that the data is not altered when flowing from one module to another.

Once all the components have been integrated and tested, we conduct Systems testing to test the entire application/system as a whole. This test confirms whether the business requirements align with the implemented software.

Conclusion

I would propose that Unit testing and Component testing are conducted simultaneously.

Contrary to Unit testing, which is performed by the development team, Component/module testing is conducted by the Testing team. It’s always recommended to fully test the components before initiating Integration testing.

If Component testing is solid, we will identify fewer defects in integration testing. There will still be issues but those issues would be related to the integration environment or configuration challenges. You can confirm the functionality of the integrated components is operating fine.

I hope this tutorial helped you to understand Component, Integration, and System testing. If you still have queries, please feel free to ask them in the comments.