This is the documentation for Clover 4.0. View this page for the

Unknown macro: {spacejump}

of Clover, or visit the latest Clover documentation.

'Current' Clover reports display graphical and numerical data relating to the most recent coverage data collected for the project.

 

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.

 

ADG report style (Clover 4 only)

Project overview page

General

On the project overview page you will find several tabs, thanks to which you can quickly learn about your project:

  • Dashboard - contains several widgets with statistics and most critical issues
  • Application code - browse through application classes
  • Test code - browse through test classes
  • Test results - contains results from your unit tests
  • Top risks - the most complex and the least covered classes
  • Quick wins - "low hanging fruits"
  • Coverage tree map

 

Blue application header

  • Clover logo - opens the Atlassian Clover home page
  • Linked reports - shows reports linked with the current one (optional, see the <clover-report> task for more details)
  • Help icon - opens the Clover documentation home page

 

Dashboard tab

It contains several useful widgets:

  • Code coverage - shows Total Coverage Percentage metric of your application code (i.e. excluding test code)
  • Test results - shows number of tests executed and their success ratio
  • Code metrics - shows code metrics of your application code of the entire project (i.e. excluding test code)
  • Class coverage distribution - histogram showing number of classes vs coverage
  • Class complexity - dot chart showing class complexity vs coverage
  • Coverage tree map - size of the rectangle represents package complexity, while colour shows its coverage
  • Top project risks - the most complex and the least covered classes
  • Most complex packages - packages with the highest cyclomatic complexity
  • Most complex classes - classes with the highest cyclomatic complexity
  • Least tested methods - methods having the lowest code coverage

Package tree view

You can use it to navigate through the project structure. You can also search for packages matching given sub-string.

 

 

Package-level and project-level overview of application and test code

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.

Source file view

This page contains few sections:

  • code metrics for current source file
  • list of classes in the source file, the "Show methods" opens a dialog showing detailed data for a class
  • number of tests "hitting" the source file, the "Select tests to highlight the test coverage" opens list of tests; it's possible to select them to see per-test coverage
  • source code view page with highlighted code coverage

 

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.

 

Test results

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.

 

'Top risks' and 'Quick wins' tag clouds

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.

 

 

Coverage tree map

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:

  • green for most covered
  • red for least covered

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.

See also: 'Historical' Report.

Classic report style (Clover 3 and Clover 4)


The screen shot below shows a generated Classic HTML report.

  • In the top left-hand corner is the list of packages. You can view all classes in the project or select a particular package to view. Clicking on the name of a package will bring up the relevant classes in the frame below it. Selecting one of these classes will bring up the source code in the frame on the right.
  • The header provides summary information relating to the current project. The left hand side displays the report title and the time of the coverage contained in the report. For current reports, the timestamp is the timestamp of the most recent run of tests. The right hand side of the header displays metrics for the package, file or project overview which is currently selected. Depending on the current selection, the metrics include all or a subset of:
    • Number of Lines of Code (LOC)
    • Number of Non-commented Lines of Code (NCLOC)
      (info) This information is currently not available with Clover reports on Groovy code.
    • Number of Methods
    • Number of Classes
    • Number of Files
    • Number of Packages.
  • Test coverage is indicated by colour-coding. For details, click 'SHOW HELP' in the report header.
  • Inline help appears when you mouse-over any column header, button, etc.

 

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

 

Appendix: naming convention of lambda functions

Naming convention for Java 8 lambda functions is as follows: <lambda_prefix><parameter_list><sequence_number> where:

  • <lambda_prefix> is $lam
  • <parameter_list> is a list of argument names separated by underscore, like x_y_z; list can be empty
  • <sequence_number> is #N where N counts definitions of a lambda function in given source file (starting from 0)

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?

  • if you use meaningful names of lambda arguments, you'll be able to easily find such lambda function on a list
  • sequence number helps to distinguish zero-argument lambda functions