Integration Testing

This tests a group of related units together and their interface. This comes from interface specifications and tests module interactions.

Failures from integration testing well-tested modules could be caused by:

• Bad use of interfaces
• Wrong hypothesis on the behaviour/state of related modules
• Use of poor drivers/stubs: a module may behave correctly with simple stubs but result in failures when integrated with actual modules

Stubs

This replaces a called module or whole components. This must be declared and invoked as a real module (mimic everything about it). Common functions include:

• Display / print trace messages
• Display / print passed parameters
• Return value according to test objective:
  • From table
  • From external file
  • Based on a search according to param value

Drivers

Drivers are used to call tested modules for parameter passing and handling return values. These are simpler than stubs.

Strategies

This impacts the order of integration, the form in which unit tests are written, the cost of generating tests, the cost of locating defects.

Strategies include:

• Big bang
  • This is non incremental and integrates all components as a whole
  • Assumes components are initially tested in isolation
  • Advantages
    • Convenient for small/stable systems
  • Disadvantages
    • Does not allow parallel development
    • Fault localization difficult
    • Easy to miss interface faults
• Top down
  • Incremental strategy
  • Test high-level components, then called components until lowest-level components
  • You can alter the order to test critical components as early as possible
  • Advantages
    • Fault localization is easier
    • Few or not drivers needed
    • Possibility to obtain an early prototype
    • Testing can be in parallel with implementation
    • Major design flaws are found first
  • Disadvantages
    • Needs lots of stubs
    • Potentially reusable components might be inadequately tested (at the bottom)
• Bottom up
  • Incremental strategy
  • Tests low-level components, then components calling them until highest-level component
  • Advantages
    • Fault localizations easier
    • No need for stubs
    • Reusable components tested thoroughly
    • Testing can be in parallel with development
    • Different order of testing/implementation possible
  • Disadvantages
    • Needs drivers
    • High-level components are tested last
    • No concept of early skeletal system
• Sandwich
  • Combines top-down and bottom-up approaches
  • Distinguishes three layers:
    • Logic (top) is tested top down
    • Middle
    • Operational (bottom) is tested bottom up
• Risk driven
  • Integrates based on criticality (most critical components integrated first)
• Function / thread-based
  • Integrate components according to the threads/functions they belong to

Summary Table

Comparison criteria:

• Fault localization
• Effort needed
• Degree of testing of modules achieved
• Possibility for parallel development

Testing OOP

Classes introduces different scopes of integration testing:

• Cluster Integration
• Integration of components into a single application
  • Similar techniques for cluster integration also applicable at this level
  • Client/server integration