Posted on 21 February 2007
While reading about unit testing, I was wondering if there was a way to find out the number of test cases that would be needed to test the class completely. A large class can have large number of independent execution paths, which would be adopted. There are execution points which are independent of each other. This may lead to a situation where an execution path is covered while testing, but has not been specifically tested. So a 100% code coverage does not necessarily reflect 100% testing of the code.
Here comes cyclomatic complexity to the programmer’s help. This is an ordinal number which would be an indication of the total number of different execution paths a method may follow. This may give us a fairly good idea of how many test cases one would need to actually 100% test a given code class. For example if a method has a CC equal to 2, it requires two unit tests. If all tests indicated by CC are written, it would definitely lead to a 100% coverage.
Thomas McCabe in 1976, it measures the number of linearly-independent paths through
a program module. It is independent of a programming language and its format. It has been widely
accepted as a measure of the software programming metrics and is a good measure of soundness of
a piece of code.
The cyclomatic complexity of a software module is calculated from a connected graph of the module (that shows the topology of control flow within the program):
Cyclomatic complexity (CC) = E - N + p
where E = the number of edges of the graph
N = the number of nodes of the graph
p = the number of connected components
To actually count these elements requires establishing a counting convention (tools to count cyclomatic complexity contain these conventions). The complexity number is generally considered to provide a stronger measure of a program’s structural complexity than is provided by counting lines of code.
As per Carnegie Mellon Univ., A low cyclomatic complexity contributes to a program’s understandability and indicates it is amenable to modification at lower risk than a more complex program. A module’s cyclomatic complexity is also a strong indicator of its testability.
A CC of 1-10 indicates a simple program without much risk. A CC of 11-20 reflects a more complex, moderate risk program. From 21-50, it indicates a complex and high risk program. At greater than 50, it is considered to be untestable.
The usage of this number can be applied to
- Code development risk analysis: May indicate inherent risk in a module, which can then be refactored.
- Change risk analysis in maintenance: Measuring it before and after changes, it can be monitored to help decide the risk of change.
- Test planning: Indicates the numberof test cases required for a particular piece of code.
- Reengineering: Higher the CC, higher is the risk in rewriting that module code.
Now going to look for tools that may tabulate CC for a given piece of code.