Bottom-up Integration

The bottom-up approach requires the lowest-level units to be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized.


The strengths of Bottom-Up Testing overcome the disadvantages of Top-Down Testing. Additionally, drivers are easier to produce than stubs and because the tester is working upwards from the bottom layer, they have a more thorough understanding of the functioning of the lower layer modules and thus have a far better idea of how to create suitable tests for the upper layer modules.


  1. It is more difficult to imagine the working system until the upper layer modules are complete
  2. The important user interaction modules are only tested at the end
  3. Drivers, often many different ones with varying levels of sophistication, must be produced.

Bottom-up Integration example

Top-Down Integration vs. Bottom-Up Integration

  • Top-down integration has the “advantage” (over bottom-up integration) that it starts with the main module, and continues by including top-level modules – so that a “global view” of the system is available early on.
  • It has the disadvantage that it leaves “utility modules” until the end so that problems with these won’t be detected early. If “bottom-up” integration is used then these might be found soon after integration testing begins.
  • Top-down integration also has the disadvantage or requiring stubs – which can sometimes be more difficult to write than drivers, since they must simulate computation of outputs, instead of their validation

Was this article helpful?

Related Articles