What is Module Testing? Definition, Examples

What is Module Testing?

Module testing is a software testing type which checks individual subprograms, subroutines, classes or procedures in a program. Instead of testing the whole software program at once, module testing recommends testing the smaller building blocks of the program.

Module testing is largely white box oriented. The objective of module testing is not to demonstrate the proper functioning of the module, but to demonstrate the presence of an error in it. That inversion matters: a run that finds nothing has confirmed very little, whereas a run that exposes a defect has done its job.

Module level testing also allows parallelism to be introduced into the testing process, because it creates the opportunity to test multiple modules simultaneously instead of waiting for a complete build.

Why to do Module Testing

Module testing is recommended because it changes the economics of defect detection.

• The probability of identifying errors or bugs in smaller chunks of a program becomes higher.
• Multiple modules can be tested simultaneously, and the approach therefore supports parallel testing.
• The complexity of testing can be managed easily, since each module is reasoned about on its own.
• A defect found inside one module is traceable to a small amount of code, so debugging time drops sharply.

How to do Module Testing?

Designing a test case is the important segment of module testing. While designing test cases for a module test, a tester has to take two things into consideration.

• Specification for the module
• The module’s source code

Analyze the module’s logic by using one or more of the white box methods, and then supplement these test cases by applying black box methods to the module specification. Realistic values matter as much as the paths chosen, so prepare the test data alongside the cases rather than afterwards.

Once the test cases are designed, the next step is to combine the modules for testing. The method used is either an incremental or a non-incremental method.

• Non-incremental method — all modules are tested independently. It first combines all the modules and then tests the whole program.
• Incremental method — each module is tested first and is then gradually added to the tested collection. It performs a step-wise retest.
• Within incremental testing there are two approaches, top down and bottom up testing.
• To execute the module with the selected data, a driver is required for supplying the test data, monitoring the execution and capturing the results.

The choice between the two methods is a trade-off between setup effort and diagnosability.

Drivers and Stubs in Module Testing

The driver mentioned above is one half of a pair. Because a module under test rarely sits at the top or the bottom of the call chain, testers substitute dummy code for whatever is missing on either side of it.

• Driver — replaces the calling module above the one under test. It supplies the test data, invokes the module, monitors execution and captures the results. Bottom up testing depends on drivers, because the lower modules are ready before the higher ones.
• Stub — replaces a called module below the one under test. It accepts the call and returns a fixed, known response so the module under test can complete its path. Top down testing depends on stubs, because the higher modules are ready first.

A worked case makes the pairing concrete. If a payment-calculation module is finished while the checkout screen that calls it is not, a driver feeds the module a set of order totals and records what comes back. If the tax-lookup service the module calls is also unfinished, a stub returns a fixed tax rate so the calculation still runs. Neither piece of scaffolding ships; both are discarded once the real modules arrive, which is why misunderstanding test doubles is listed later as a recurring challenge.

Example Tips for Module Testing

Here are a few tips to consider before performing module testing.

• Review test cases before using them.
• Avoid confusion over the source of discrepancies.
• Use automated test tools.
• Examine variables that should be unchanged.
• Swap modules between testers to avoid self-tests.
• Re-use the test cases.

The fifth tip carries more weight than its length suggests. A developer who tests only the module just written repeats the same assumptions that produced the defect, so rotating modules between people is one of the cheapest quality gains available.

Unit Testing vs Module Testing

The two terms are used interchangeably in many teams, yet the authorship and the scope differ.

Module Testing vs Component Testing vs Integration Testing

Module testing also sits next to two neighbouring levels that are easy to confuse with it. The table separates them by what is under test and who normally performs it.

In everyday usage component testing and module testing are frequently treated as the same activity, while integration testing begins only once the individual modules have each passed on their own.

Challenges in Module Testing

These are the challenges teams meet most often when module testing is introduced.

• Non-incremental testing requires more work — combining everything first means a single failure can send testers back through the whole program.
• Misunderstanding test doubles — a stub that returns an unrealistic value produces a green run that proves nothing.
• Debugging tests often — scaffolding code carries its own defects, and time spent fixing a driver is time not spent testing the module.
• Need to understand the code — the white box orientation means a tester who cannot read the module cannot design meaningful cases for it.

FAQs