Top Down Integration Testing

Top down integration testing is a technique where the behaviour of the lower-level modules is yet to be integrated and simulated. In this type of test, the highest-level logic and flowing of data is tested early in this process.

While stubs are modules that act temporarily as replacement for a module called and give the exact output as would with the actual product, it's therefore used to simulate the sub modules, these are also used when the software has to interact with an external system.

Few advantages OF Top Down Integration Testing are as follows:

  • Its major flaws occur toward the top of the program, in cases whereby the I/O functions are included.
  • Representation of test cases is made clear and lastly early skeletal program allows demonstrations that ultimately help to boost morale for better results in general.
  • However, stubs modules must be produced that increases work in the end. These stubs are often more complex than they first appear to be. Hence, dragging the process a little longer is not considered to be a great idea in itself.

Disadvantages of Top Down Integration testing are as follows:

  • Unable to design stubs that offers an easy way of emulation and interacts at different levels.
  • On adding lower layers, the upper layers are supposed to re-evaluate.
  • The lower level cannot be manipulated after higher levels being closed.

The representation of test cases in stubs can be difficult especially before the I/O functions are added and even then test conditions may prove to be impossible or extremely difficult to create, this in turn also makes observation of test output seemingly difficult.

Top down integration allows one to believe and assume that designing and testing can be overlapped which may not be the case and lastly it induces one to defer completion of the testing of certain modules. Considering it is always good to evolve the software and test software in pieces. Although it might be hard to imagine, if any of the pieces are left to be under developed and left incomplete.

There are four basic types of stubs for top-down testing. These are namely:

  1. Displays a trace message.
  2. Display parameter values.
  3. Return a value from a table.
  4. Lastly return table value selected by parameter.

Stubs are said to be kept at a minimum level of complexity and this is mainly to avoid inducing errors when testing the unit in question even though they are viewed as throw away code but do not necessarily need to be thrown away as they can be filled in to form the actual method.

Stubs are mainly used because it's always a good idea to develop and further test software in pieces which is where stubs and drivers come in. Since software applications are made of units where ones output goes as an input into the other, for such reasons independent testing of a unit is not possible thus the use of a stub in order to test each unit in isolation making the software easier to use and also very effective for whatever purpose its being developed for which is the ultimate result for any software developed, with little or no errors.