What is a Component Testing? (Techniques, Example Test Cases)

Software TestingAutomation TestingTesting Tools

Component Testing

It's similar to white-box testing. Component testing looks for flaws and checks the functionality of modules/programs that may be tested independently.

In software testing, component testing is also known as module testing. Any application's smallest unit is called a component. So, component testing is a strategy for evaluating the smallest or lowest unit of any program, as the name implies.

Component testing is also known as Program or Module testing in some cases

An application is made up of numerous little independent modules that have been combined and integrated. It is critical that each component OR the smallest element of the application be extensively verified before the complete system is evaluated.

The modules or units are checked separately in this scenario. Each module gets an input, processes it, and then outputs it. After that, the output is compared to the predicted characteristic.

Because the software applications are so large, testing the entire system is difficult. It might result in a lot of test coverage gaps. As a result, it's a good idea to start with component testing before going on to integration or functional testing.

The phrase "component testing" has different meanings in different domains and organizations.

Component testing is commonly misunderstood for a variety of reasons.

  • Selecting a Development Life Cycle Model

  • The degree of difficulty of the program or application being tested

  • Testing with or without isolation from the rest of the program or application's components.

The Software Test Life Cycle Architecture, as we all know, contains a huge number of test artifacts (Documents made, used during testing activities). The Test Policy & Test Strategy is one of several tests – artifacts that describe the types of testing and the degree of testing to be done in a project.

Who does Component Testing?

Testers are in charge of component testing. The developers undertake ‘Unit Testing,' in which they test each particular functionality or method. After unit testing is completed, component testing is conducted. The testers are in charge of component testing.

What exactly is tested as part of component testing?

Verifying functional or specified non-functional properties of system components may be part of component testing.

It can include resource behavior testing (for example, detecting memory leaks), performance testing, and structure testing, among other things.

When Should Component Testing Be Performed?

Component testing occurs shortly after the developers have completed Unit Testing and the build has been delivered to the testing team. This build is known as the UT build (Unit Testing Build). During this phase, all of the components' major functionality is tested.

Component testing entry requirements −

  • The UT should have a minimum number of components that have been created and unit tested.

Component testing exit requirements

  • All of the components' functionality should be operating properly.

  • There should be no critical, high, or medium severity, or priority defects in the defect log.

Test approach for component testing

Component testing is separated into two sections, depending on the degree of testing −

  • Component Testing in Small (CTIS)

  • Component Testing in Large (CTIL)

Component testing in tiny refers to component testing done in isolation with other components. This is done without taking into account the integration of other components.

Example 1 − If a website has five different web pages, component testing in small refers to testing each web page independently while isolating other components.

Component testing in big refers to component testing that is performed without isolation from other software components. This occurs when the components' functionality flow is dependent on each other, and we are unable to segregate them.

We utilize fake objects in place of the actual components if the components on which we rely have not yet been built. The stub (also known as a function) and driver are two fake objects (calling function).

Drivers and Stubs

Before I go into detail about Stubs and Drivers, it's important to understand the distinction between component and integration tests. The reason for this is that stubs and drivers are also used in integration testing, which may cause some misunderstanding between the two testing methods.

Integration testing is a process in which two components are combined sequentially and the integrated system is tested as a whole. Data is sent from one system to another, and the integrity of the data is checked for the integrated system.

Unlike module testing, which fully tests a single component or module before combining it with other components. As a result, component testing comes first before integration testing.

Stubs and Drivers are used in both Integration and Component.

When the calling function does not exist, dummy programs called "drivers" are used to call the functions of the lowest module.

The term "Stubs" refers to a code snippet that receives inputs/requests from the top module and delivers the results/response.

The components are evaluated individually and independently, as previously stated. As a result, some functionality of the components may be dependent on another component that is not presently being developed. So, in order to test the components with these "undeveloped" capabilities, we'll need some stimulating agents to analyze the data and send it to the calling components.

We can ensure that all of the various components are fully checked this way.

Here's what we can see

  • C1, C2, C3, C4, C5, C6, C7, C8, and C9 ------ are the components

  • Subunit 1 is made up of C1, C2, and C3.

  • Sub Unit 2 is made up of C4 and C5.

  • Sub Unit 3 is made up of C6, C7, and C8.

  • Component 4 is formed solely by C9.

  • Business Unit 1 is made up of Subunit 1 and Subunit 2.

  • Business Unit 2 is made up of Sub Unit 3 and Sub Unit 4.

  • The application is made up of Business Unit 1 and Business Unit 2.

  • In this example, component testing would entail evaluating the individual components C1 through C9.

  • The Integration testing point is shown by the red arrow between Sub Unit 1 and Sub Unit 2.

  • Similarly, the Integration testing point is shown by the red arrow between Sub Units 3 and 4.

  • The integration testing point is shown by the green arrow between Business Unit 1 and Business Unit 2.

As a result, we would −

  • c1 to c9 component testing

  • testing of integration between subunits and business units

  • system testing of the entire application

A Case in Point

We must have demonstrated that component testing is a white box testing approach up to this point. You may be correct. However, this does not rule out the possibility of using this approach in Black box testing.

Consider a large online app that begins with a Login page. We couldn't wait till the full application was created and ready to test as testers (especially in an agile setting). We must begin testing as soon as possible in order to reduce our time to market. As a result, once the Login page is complete, we must demand that it be made available for us to test.

You may run all of your test cases (positive and negative) to check that the Login page functionality is operating as intended as soon as you have the Login page accessible for testing.

The following are some of the benefits of testing your login page at this time −

  • The usability of the user interface is evaluated (spelling mistakes, logos, alignment, formatting, etc.)

  • Negative testing approaches such as authentication and authorization should be used. There's a good chance you'll uncover flaws in these situations.

  • The use of methods such as SQL Injections ensures that security breaches are detected at an early stage.

The problems you report at this stage will serve as "lessons learned" for the development team, which will be included in the coding of the next page. As a result, by testing early, you can assure that the pages that are still being created are of higher quality.

Because the next few pages aren't ready yet, you might need stubs to test the login page's functioning. For example, you could want a basic page that says "logging succeeded" if the credentials are valid, and an error message popup window if the credentials are incorrect.

Unit Testing vs. Component Testing

The primary distinction between component testing and unit testing is that the former is carried out by testers, whilst the latter is carried out by developers or SDET experts.

Unit testing is done at a very fine level. Component testing, on the other hand, is done at the application level. Unit testing verifies that a single program or piece of code is being executed according to the specifications. In component testing, each software item is tested independently, either with or without isolation from other system components/objects.

Component testing is similar to unit testing, but it is carried out at a higher degree of integration and in the context of the entire application (rather than simply the unit/program).

Component Testing vs. Interface Testing vs. Integration Testing vs. Systems Testing

As previously stated, a component is the smallest unit of an application that is tested separately. An interface is a layer that connects the two components. Interface testing is the process of evaluating the platform or interface via which the two components communicate.

Trying out the UI is now a little different. Because these interfaces are primarily APIs or Web Services, testing them would not be analogous to Black Box testing; instead, you would use SOAP UI or another tool to do API or Web Service testing.

After the Interface testing, the Integration testing begins. We integrate the different tested components one by one and test them progressively during the Integration test. During integration, we ensure that the various components, when joined one by one, perform as intended and that data is not tampered with as it flows from one module to the next.

We undertake Systems testing to test the complete application/system once all of the components have been merged and tested. This test compares the implemented software to the business requirements.


Unit testing and component testing, in my opinion, should be done concurrently.

The Testing team is in charge of component/module testing, whereas the Development team is in charge of unit testing. Before starting Integration testing, it's generally a good idea to conduct some thorough component testing.

We will uncover fewer faults in the integration testing if the component testing is flawless. There would be problems, but they'd be due to the integration environment or configuration difficulties. You may verify that the combined components' functioning is correct.

Updated on 02-Dec-2021 05:23:22