<P> In general, in order to fully test a module, all execution paths through the module should be exercised . This implies a module with a high complexity number requires more testing effort than a module with a lower value since the higher complexity number indicates more pathways through the code . This also implies that a module with higher complexity is more difficult for a programmer to understand since the programmer must understand the different pathways and the results of those pathways . </P> <P> Unfortunately, it is not always practical to test all possible paths through a program . Considering the example above, each time an additional if - then - else statement is added, the number of possible paths grows by a factor of 2 . As the program grows in this fashion, it quickly reaches the point where testing all of the paths becomes impractical . </P> <P> One common testing strategy, espoused for example by the NIST Structured Testing methodology, is to use the cyclomatic complexity of a module to determine the number of white - box tests that are required to obtain sufficient coverage of the module . In almost all cases, according to such a methodology, a module should have at least as many tests as its cyclomatic complexity; in most cases, this number of tests is adequate to exercise all the relevant paths of the function . </P> <P> As an example of a function that requires more than simply branch coverage to test accurately, consider again the above function, but assume that to avoid a bug occurring, any code that calls either f1 () or f3 () must also call the other . Assuming that the results of c1 () and c2 () are independent, that means that the function as presented above contains a bug . Branch coverage would allow us to test the method with just two tests, and one possible set of tests would be to test the following cases: </P>

What is cyclomatic complexity explain with an example