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.


Introduced by 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.

Usage Considerations

The usage of this number can be applied to

  1. Code development risk analysis: May indicate inherent risk in a module, which can then be refactored.
  2. Change risk analysis in maintenance: Measuring it before and after changes, it can be monitored to help decide the risk of change.
  3. Test planning: Indicates the numberof test cases required for a particular piece of code.
  4. 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.