Structured Testing - McCabe and Associates

Consideration of the intent behind complexity limitation can keep standards policy on track.
There are two main facets of complexity to consider: the number of tests and everything else
(reliability, maintainability, understandability, etc.). Cyclomatic complexity gives the number
of tests, which for a multiway decision statement is the number of decision branches. Any
attempt to modify the complexity measure to have a smaller value for multiway decisions will
result in a number of tests that cannot even exercise each branch, and will hence be inadequate
for testing purposes. However, the pure number of tests, while important to measure and control,
is not a major factor to consider when limiting complexity. Note that testing effort is
much more than just the number of tests, since that is multiplied by the effort to construct each
individual test, bringing in the other facet of complexity. It is this correlation of complexity
with reliability, maintainability, and understandability that primarily drives the process to
limit complexity.
Complexity limitation affects the allocation of code among individual software modules, limiting
the amount of code in any one module, and thus tending to create more modules for the
same application. Other than complexity limitation, the usual factors to consider when allocating
code among modules are the cohesion and coupling principles of structured design: the
ideal module performs a single conceptual function, and does so in a self-contained manner
without interacting with other modules except to use them as subroutines. Complexity limitation
attempts to quantify an “except where doing so would render a module too complex to
understand, test, or maintain” clause to the structured design principles. This rationale provides
an effective framework for considering exceptions to a given complexity limit.
Rewriting a single multiway decision to cross a module boundary is a clear violation of structured
design. Additionally, although a module consisting of a single multiway decision may
require many tests, each test should be easy to construct and execute. Each decision branch
can be understood and maintained in isolation, so the module is likely to be reliable and maintainable.
Therefore, it is reasonable to exempt modules consisting of a single multiway decision
statement from a complexity limit. Note that if the branches of the decision statement
contain complexity themselves, the rationale and thus the exemption does not automatically
apply. However, if all branches have very low complexity code in them, it may well apply.
Although constructing “modified” complexity measures is not recommended, considering the
maximum complexity of each multiway decision branch is likely to be much more useful than
the average. At this point it should be clear that the multiway decision statement exemption is
not a bizarre anomaly in the complexity measure but rather the consequence of a reasoning
process that seeks a balance between the complexity limit, the principles of structured design,
and the fundamental properties of software that the complexity limit is intended to control.
This process should serve as a model for assessing proposed violations of the standard complexity
limit. For developers with a solid understanding of both the mechanics and the intent
of complexity limitation, the most effective policy is: “For each module, either limit cyclomatic
complexity to 10 (as discussed earlier, an organization can substitute a similar number),
or provide a written explanation of why the limit was exceeded.”
16