Clover 4 brings new HTML report developed according to the Atlassian Design Guidelines; it's shortly named "ADG". Clover 3 offers an old-style JavaDoc-like format, named "Classic". It is still possible to fall-back to the "Classic" report in Clover 4, however this report style is deprecated.
General
On the project overview page you will find several tabs, thanks to which you can quickly learn about your project:
Blue application header
Dashboard tab
It contains several useful widgets:
Package tree view
You can use it to navigate through the project structure. You can also search for packages matching given sub-string.
The "Application code" and the "Test code" tabs show list of packages along with their metrics and their code coverage.
In case of a project-level overview, there is an additional toggle "Metrics from sub-packages: Separated / Aggregated", which allows to calculate an aggregated code coverage and code metrics, i.e. given package will include also metrics from its sub-packages.
Table columns are sortable and customizable.
This page contains few sections:
In the source view, the left-most column shows line numbers. The second column shows the number of times a particular line has been executed during the test run.
If a line is never executed or has only been partially executed, the entire line of code will be highlighted in red. You can hover the mouse over a line to get a pop-up describing in detail the coverage information for that line.
You can click on the 'Show legend' button to see more details about highlighting.
Rendered code provides also source cross referencing and stack trace navigation.
The "Test results" tab shows information about executed tests - for an entire project, a package, a class as well as for a single test case.
What is worth to note is that a class-level summary may contain multiple tests having the same name - it may happen in case you have executed test several times or you have used a test framework allowing test iterations (for instance, the JUnit4 with @Parameterized annotation or the Spock framework).
A test case page shows detailed information like test result, duration, stack traces (if any) as well as a list of classes which were covered by the test.
The Top Risks tag cloud highlights those classes that are the most complex, yet are the least covered by your tests. The larger and redder the class, the greater the risk that class poses for your project or package. Font size represents the Average Method Complexity metric, while the colour represents the Total Coverage metric (red for 0%, green for 100%).
The Quick Wins tag cloud highlights the "low hanging coverage fruit" of your project or package. You will achieve the greatest increase in overall code coverage by covering the largest, reddest classes first. Big red classes contain the highest number of untested elements. Font size represents the Number of Elements metric, while the colour represents the Number of Tested Elements from red - minimum tested elements to green - maximum).
Note: For Clover 4.0.4 and lower those metrics had different colour scheme.
The coverage tree map report allows simultaneous comparison of classes and packages by complexity and by code coverage. This is useful for spotting untested clusters of code. The tree map is divided by a package (labelled) and then further divided by a class (unlabelled). The size of the package or class indicates its complexity (larger squares indicate greater complexity, while smaller squares indicate less complexity). Colours indicate the level of coverage, as follows:
Clicking on a class will navigate you to the corresponding source file view.
Note: For Clover 4.0.4 and lower this metric had different colour scheme.
The screen shot below shows a generated Classic HTML report.
The screen shot shows the report for the Money.java
source file with the green and red bar at the top showing the amount of code coverage on this class. The method, statement and conditional coverage percentages are beside this.
The left-most column shows line numbers. The second column shows the number of times a particular line has been executed during the test run. As you can see, lines 15-17 have been run 156 times by the JUnit tests, whereas line 28 has only been run twice.
If a line is never executed or has only been partially executed, the entire line of code will be highlighted in red. Depending on your browser, you can hover the mouse over a line to get a popup describing in detail the coverage information for that line. The following screenshot shows the coverage on a section of the MoneyBag.java
source file:
Although line 52 of the above MoneyBag
class has been executed 14 times, the method isZero()
has never evaluated to true
so it has not been fully tested. Therefore it, and the following two lines, are highlighted. This is also the case with lines 58 and 59.
This highlighting feature makes it easy for you to see which parts of the code have not been fully exercised by your tests so that you can then improve testing to provide better code coverage.
If any of the lines shaded red contained a bug, they may never be detected because the tests as they are don't test those parts of the code.
If you click on a [+] button on the left side of the class name, table will expand and show methods declared in it. If the HTML report was generated with showLambdaFunctions=true and showInnerFunctions=true options, the table will also show lambda functions declared inside methods or assigned to a class field.
Screen shot: sample report for code containing lambda functions
Naming convention for Java 8 lambda functions is as follows: <lambda_prefix><parameter_list><sequence_number> where:
For example: $lam_x_y_z#6 means a sixth lambda in the source file having the (x, y, z) => signature.
Why such naming convention?