'''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