Metrics
CoView and Comet analyze code using a manageable set of industry-standard metrics.
| Metric | Impact |
|---|---|
| Cyclomatic Complexity | Cyclomatic Complexity (CC) is a measure of the decision logic in a method. The more decisions your method has, the more ways it will behave. Keeping the number of CC paths to 10 or less greatly reduces the risk of defects as well as increases the overall testability of your code. |
| Exceptions | Each thrown exception represents a distinct error condition that must be tested, and error conditions are very hard to test. Keeping the number of thrown exceptions to three or less greatly simplifies your testing effort. |
| Parameters | Each parameter added to a method's signature increases the number of possible ways that method can be invoked, eventually creating an unmanageable combinatorial problem. By limiting the number of parameters to three or fewer, you can easily increase the testability of your code. |
| Lines of Code | One of the oldest and simplest metrics used to measure a method's testability. A shorter method is easier to understand and test. We suggest limiting your methods to 50 lines of code or less. |
| Define-Use Paths | This metric looks at distinct data paths. Data paths are paths that link a data element's definition to its use. In other words, if you define a data element, you should use it, and if you use it, you should test it. Data paths often overlap with Cyclomatic Complexity paths, which is why we suggest a similar threshold of 10. |
| Static Invocations | Methods under test invoke methods from external classes, and these external classes can usually be mocked or dummied up to behave exactly as required for an individual unit test. Static invocations of external methods often have an unchangeable behavior that thwarts even the best testing effort. Avoid this unnecessary coupling to external classes, and keep your external static invocations to a minimum. |
| Anonymous Classes | Anonymous classes make unit testing difficult because they exist only within the method under test, and cannot themselves be unit tested. Although anonymous classes are convenient (especially for GUI programming), their lack of testability and mockability can hinder your testing effort. |
| Branch Coverage | A high coverage percentage indicates a strong testing effort and ensures that a greater percentage of decision logic has been fully tested. Keeping the other testability metrics low will make it easier for you to have a high branch coverage metric, giving you peace of mind that only high coverage can bring. |
| Number of JUnit Tests | In a perfect world, you should have one unit test for every decision, data element and boundary condition in your method. In the real world, 100% coverage is not always possible. The number of actual tests possible will vary by method and project, but having even a single JUnit test can flush out otherwise hidden problems. |