Cluster Integration

Used for integration testing OOP

• Integration of two or more classes through inheritance (cluster)
• Integration of two or more classes through containment
• Integration of two or more associated classes to form a component or subsystem
• Bottom-up or top-down testing or scenario based testing

Note

A class dependency tree is required here since structure is not always clear cut.

These techniques are typical Integration Testing techniques but have additional detail for testing OOP.

Big Bang

This is recommended when the cluster is stable and only a few elements are added or changed and components are tightly coupled (hard to test separately in practice).

Bottom-Up

This is the most widely used technique. Integrate classes starting from leaves and move up the dependancy tree.

Top-Down

This is still a popular technique where we integrate classes starting from the top moving downwards.

Scenario Based

Describes class interactions and is represented as interaction diagrams.

1. Map collaborations onto dependency tree
2. Choose a sequence to apply collaborations
3. Develop and run test exercising collaboration

Tip

Here we could test one branch of a class dependency tree at a time, and stub the other nodes not being tested.

Integration Order Problem

You usually do not want to perform a big-bang integration of classes since you need to do step-wise integration leading to Test Stubs. It may not always be feasible to make a stub that is simpler than the code it simulates. This also cannot be automated (one of those things a human should do). The fault potential for some stubs may be the same or higher than that of the real function. Minimizing the number of stubs should result in drastic savings.

Class dependency graphs typically do not form simple trees but rather complex networks, maybe with cycles.

Kung et al. Strategy

This aims at producing a partial ordering of testing levels based on class diagrams. Classes under test at a given level should only depend on classes previously tested. No stubs are required since previously tested classes can be included in subsequent testing levels.

You can figure out class dependency from reverse engineering or docs.

• Object Relation Diagram A desirable order for testing is one that minimizes the number of stubs or stubbing effort. Test independent classes first, then test dependent classes based on relationships.

Acyclic ORDs

• Generate a test order that makes sure that X is tested before $CFW(X)$ without needing stubs by doing Kung et al. which is a Topological Sort.

Dynamic Binding

• Kung et al, does not take into account dynamic relationships (polymorphism for abstract imposes an order and abstract classes make it infeasible since abstract classes are technically top level in the topological sort)
• For example, if a class is abstract, its source code is tested in a class that implements it, tightly coupling them.