Isolate And Integrate

Pattern Name: IsolateAndIntegrate

Aliases: Unit Testing

Context: Parts of a system interact in a large number of ways that are difficult to keep track of. In addition, the performance of each part is not well-known.

Problem: The system as a whole is not performing well. Each part of the system does not reveal if it is the main cause of the problem.

Forces: Each part does not yield easily to testing. Typically each function has been determined to work based on its behavior while the system is up and running as a whole. This creates many small fixes to each part that, over time, lack any formal architecture.

Solution: Map out the architecture of the current system in large blocks, looking for minimal interfaces between each part. Create a testing environment for these parts that will simulate a broad range of semi-realistic scenarios that can be catalogued and re-used. After each part has been tested for general behaviors and functions, sub-divide each part into smaller blocks, creating simulation environments as before. After a reasonable granularity has been reached, look for ways to simplify and enhance the interfaces between the parts and their sub-parts. Re-integrate the parts bottom-up, checking for conflicts and opportunities to resolve long-standing issues as much as possible.

Resulting Context: As with many other patterns, the resulting context is that the behavior and functions of the system and its parts become well-known through analysis. Patterns of re-use and common interface should emerge. The ability to unit-test the different scopes of the system will ensure that any enhancements to the system components will not create conflicts that further reduce system performance.

Design Rationale: Isolating a system from its environment and creating a catalogue of test cases reveals anomalies that may not have been apparent before. This will at least explain why system performance is not up to snuff. After repairing the system at the lowest level, each part then is re-integrated into the containing sub-system. As this process goes from the atomic components on up to the whole-system level, the degree to which the system depends on synergistic interaction between its parts becomes know. This will be a driving factor in future design decisions. Typically just the act of making systems 'testable' often improves re-use, versatility, and makes the parts of the system considerably easier to document.

Examples:

Related Patterns: BeeHive, AlternateHardAndSoftLayers

-- DavidCymbala