michelangelus - Fotolia
The 4 essential Java cyclomatic complexity testing tools
Code that's less complex is easier to troubleshoot and maintain. If developers can calculate code cyclomatic complexity metrics, they have a playbook to tackle the testing phase.
When it's time to test your code, it's not good enough to simply write a unit test or two for each method. When you write unit tests, the goal is not to test every method, but also to test each instruction a method might perform. And since methods can vary greatly in terms of complexity, it's important for developers to write unit tests that cover every possible pivot, branch and condition a path of execution might take through the piece of code under scrutiny.
The number of execution paths through a given method is known as McCabe cyclomatic complexity, and every organization that understands the value of unit testing should be integrating Java cyclomatic complexity tools into their Maven builds and CI pipelines.
When developers know the cyclomatic complexity metric associated with a given method, they will know how many different unit tests to create in order to thoroughly test code. Furthermore, a high cyclomatic complexity metric is a useful indicator for team leads and Agile coaches. It can flag a story or feature that a developer is struggling to implement. As the cyclomatic complexity metric approaches 10 for any method, alarm bells should begin to ring.
So, what are the best cyclomatic complexity tools to use throughout the software development lifecycle? For any developer using Eclipse, the Eclipse Metrics Plugin is a must-have.
Java cyclomatic complexity tool for devs
The Eclipse Metrics Plugin is open source and easily installed through the Eclipse Marketplace. Eclipse users are intimately familiar with the integrated Run As and Debug As options. After adding the Eclipse Metrics cyclomatic complexity tool for Java, a new option appears called Coverage As. When you run a set of unit tests with this option, a window will appear listing all of the application's classes and methods, along with a complexity count for each. This option counts which paths were covered during the tests and provides a percentage coverage score for each class and method in the application. The Metrics plugin is a Java tool that all Eclipse developers should have on their machines.
Not every stakeholder on your team will have Eclipse installed on her local machine, so not everyone on the team will have the opportunity to run cyclomatic complexity metric checks directly on the source code. Fortunately, there are Java cyclomatic complexity tools that you can configure directly into the Maven build or make part of the testing phase of the CI pipeline.
The JaCoCo Jenkins pipeline plugin
The JaCoCo Jenkins plugin inspects the results of the various JUnit tests run during the build job's test phase and generates a code coverage report. The other neat feature of the JaCoCo Jenkins pipeline plugin is that it can be configured with thresholds. So, if the cyclomatic complexity metric exceeds 15 for any method, the plugin will fail the build. The JaCoCo Jenkins plugin can also force the build to fail if the percentage of paths -- as established through the cyclomatic complexity metric -- is not covered during testing. So, it not only provides a thorough report, but it can also ensure that untested code never makes it into production.
Continuous quality with SonarQube
SonarQube produces metrics on seven separate axes of quality, one of them being code coverage. This includes cyclomatic complexity reports. SonarQube is open source, simple to install and can easily be integrated by a Git hook or a Jenkins build job. There's no good reason not to generate quality code metrics from SonarQube as part of your DevOps build processes.
A cyclomatic complexity tool for everyone
If you're not an Eclipse developer, then you're not using Jenkins and don't have SonarQube on hand. You're in luck, though, because there is a simple, egalitarian cyclomatic complexity tool that anyone can use. I'm talking about your fingers.
Cyclomatic complexity is calculated by adding the number of loops and the number of conditionals and then adding one to that sum. It's not difficult to look at a given method and calculate the cyclomatic complexity metric on your own. Sure, it may not be an efficient method if you need to calculate every method in the code base. But during a code review or an afternoon of pair programming -- really any time a sizable method appears in the code -- a quick cyclomatic complexity calculation might be in order.
If you do this calculation by hand, it should lead to a discussion about whether all possible execution paths have been tested. Put some thought into breaking the code into multiple methods so that it's easier to test and to identify problems.
