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

What is Element Testing also known as Module Testing in Software Testing:

An element is the smallest entity of any application. So, Element testing; as the name implies, is a technique of testing the smallest or the tiniest entity of any application.

Element testing sometimes is 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 important that each component OR the smallest entity of the application is thoroughly tested.

In this case, the modules or the units are tested independently. Each module receives an input, performs some processing, and produces the output. The output is then validated against the expected feature.

The software applications are extensive 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 Element testing.

Also, peruse => Unit, Integration, and Functional Testing difference

Element Testing

It is a type of white box testing.

So, element testing looks for bugs and verifies the functioning of the modules/programs that are separately testable.

There is a test strategy and test plan for component testing. And, for each element, there is a test scenario that will be further broken down into test cases. The below diagram represents the same:

The objective of Element Testing

The main objective of element 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 as per the desired specification.

Inputs to Element Level Testing

The four major inputs to element level testing are:

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

Who Does Element Testing?

Element Testing is done by QA services or the tester.

What is tested under Element Testing?

Element testing may include 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 Element Testing is Done?

Element Testing is performed after unit testing.

Elements are tested as soon as they are created, so there are chances that the results retrieved from an element under test are dependent on other elements that are not developed yet.

Depending on the development lifecycle model, element testing may be performed in isolation from other components of the system. The isolation is done to prevent external influences.

So, to test that element, we use Stubs and Drivers for simulating the interface between software components.

Integration testing is done after element testing.

Element Testing test strategy

Depending upon the depth of testing level, element testing is divided into two parts:

1. Element Testing in Small (ETIS)
2. Element Testing in Large (ETIL)

When element testing is done in isolation from other components, it is called as element testing in small. This is done without considering integration with other components.

When element testing is done without isolation from other components of the software, then it is called as element testing in large. This happens when there is a dependency on the functionality flow of the elements, and thus we can’t isolate them.

If the elements on which we have a dependency are not developed yet, then we use dummy objects in place of the actual elements. These dummy objects can be 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 Element 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 is a technique where we combine 2 components sequentially and test the integrated system together. Data from one system is transferred to another system, and the accuracy of data is validated for the integrated system.

Unlike module testing where the single component/module is thoroughly tested before integrating it with other components. So, we can say that Element testing is performed before Integration testing.

Both Integration and Element use Stubs and Drivers.

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

“Stubs” can refer to code snippets that accept the inputs/requests from the top module and return the results/response

As explained earlier, the elements are tested individually and independently. So, there may be some features of the elements dependent on another element that is not developed currently. So, to test the elements with these “undeveloped” features, we have to use some stimulating agents that would process the data and return it to the calling elements.

This way, we ensure that the individual elements are thoroughly tested.

Here we see that:

• C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— are the elements
• C1, C2, and C3 together make the Subunit 1
• C4 & C5 together make Subunit 2
• C6, C7 & C8 together make Subunit 3
• C9 alone makes Subunit 4
• Subunit 1 and Subunit 2 combine to make Business Unit 1
• Subunit 3 and Subunit 4 combine to make Business Unit 2
• Business Unit 1 and Business Unit 2 combine to make the application.
• So, the Element testing, in this case, would be to test the individual elements which are C1 to C9.
• The Red arrow between the Subunit 1 and Subunit 2 shows the Integration testing point.
• Similarly, the Red arrow between Subunit 3 and Subunit 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:

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

An Example

Up until now, we must have established that Element testing is some type of white box testing technique. Well, it may be correct. But this does not mean that this technique cannot be used in a black box testing technique.

Consider a massive web application that starts with a Login page. As a tester (especially in an agile world), we cannot wait until the entire application is developed and ready for testing. 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 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 stage would be:

• UI is tested for usability (spelling mistakes, logos, alignment, formatting, etc.)
• Try to use negative testing techniques like authentication and authorization. There is a high probability of finding defects in these cases.
• Use techniques like SQL Injections to test for security breaches at an early stage.

The defects that you 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. By testing early, you have ensured better quality for the pages that 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 instance, you may want a simple page stating “logging successful” in case of correct credentials and an error message popup window in case of incorrect credentials.

You can refer to our earlier tutorial on Integration testing to gain more insights into Stubs and Drivers.

How to write element test cases?

The test cases for element testing are derived from work products such as software design or the data model. Each element 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 excerpt of an element test case for the Login Module.

We can write other test cases similarly.

Element Testing Vs Unit Testing

The first difference between element testing and unit testing is that the former is performed by testers while the latter is performed by developers or SDET professionals.

Unit testing is conducted at a granular level. On the other hand, element testing is done at the application level. In unit testing, it is verified if an individual program or the piece of code is being executed as specified. In element testing, each object of the software is tested separately, with or without isolation from other components/objects of the system.

So, element testing is quite similar to 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).

Element Vs Interface Vs Integration Vs Systems testing

Element, as I explained, is the smallest entity of an application that is tested independently.

An interface is the joining layer of the 2 elements. Testing the platform or the interface on which the 2 elements interact is called Interface testing.

Now, testing the interface is a bit different. These interfaces are mostly APIs or Web Services, so testing these interfaces would not be similar to Black Box techniques; 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 individually tested elements one by one and test them incrementally. We validate during Integration that the individual elements, when combined one by one, behave as expected and that the data is not altered when flowing from one module to another.

Once all the elements 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.

Conclusion

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

Unlike Unit testing, which is done by the development team, Element/module testing is done by the Testing team. It is always recommended to thoroughly test the elements before starting the Integration testing.

If the Element testing is rock solid, we will find fewer defects in the integration testing. There will still be issues, but those issues would be related to the integration environment or configuration challenges. You can ensure the functionality of the integrated elements is working fine.

I hope this tutorial was helpful in understanding Element, Integration, and System testing. If you still have questions, feel free to ask us in the comments.