Home | Forums

Contexts

Clover defines a Context as a part of source code that matches a specified structure or pattern. Contexts are either pre-defined or user-defined at instrumentation time. Each context must have a unique name. At report time, you can specify which contexts you would like to exclude in the coverage report.

Note
Contexts are matched against your source at instrumentation-time. This means you need to re-instrument your code after defining a new context.

Block Contexts

Block Contexts are pre-defined by Clover. They represent 'block' syntatic constructs in the Java language. A full list of supported Block Contexts are shown below.

namedescription
staticStatic initializer block
instanceInstance initializer block
constructorConstructor body
methodMethod body
switchSwitch statement body
whileWhile loop body
dodo-while loop body
forFor loop body
ifif body
elseelse body
trytry body
catchcatch body
finallyfinally body
syncsynchronized block
assertassert statement
@deprecateda deprecated block

Method Contexts

A Method Context represents the set of methods whose signature matches a given pattern. Clover provides several pre-defined method contexts:

nameregexpdescription
private(.* )?private .* matches all private methods
property(.* )?public .*(get|set|is)[A-Z0-9].* matches all property getters/setters

You can define your own method contexts via the <methodContext> subelement of <clover-setup>, or via the configuration panel of your Clover IDE Plugin.

Note
When matching method signatures against context regexps, whitespace is normalised and comments are ignored.

Statement Contexts

A Statement Context represents the set of statements that match a given pattern. For example, you might want to set up a statement context to allow you to filter out 'noisy' statements such as logging calls by defining a statement context regexp .*LOG\.debug.*.

Using Context Filters

Note
This section describes using context filters with Ant. For details of using filters with the IDE plugins, see the individual documentation for the plugin.

Filtering catch blocks

In some cases you may not be interested in the coverage of statements inside catch blocks. To filter them, you can use Clover's predefined catch context to exclude statements inside catch blocks from a coverage report:

   <clover-report>
  <current outfile="clover_html">
     <format type="html" filter="catch"/>
  </current>
   </clover-report>

This generates a source-level HTML report that excludes coverage from statements inside catch blocks.

Filtering logging statements

To remove logging statements for coverage reports, you'll need to define one or more statement contexts that match logging statements in your source:

   <clover-setup ...>
  <statementContext name="log" regexp="^LOG\..*">
  <statementContext name="iflog" regexp="^if \(LOG\.is.*">
     ...
   </clover-setup>

This defines two statement contexts. The first matches statements that start with LOG. while the second matches statements that start with if (LOG. which is designed to match conditional logging statements such as

   if (LOG.isDebugEnabled()) {
      // do some expensive debug logging
   }
            

Once defining these contexts you now need to re-compile with Clover and then re-run your tests. You can you then generate a report that excludes logging statements:

   <clover-report>
  <current outfile="clover_html" title="My Coverage">
     <format type="html" filter="log,iflog"/>
  </current>
   </clover-report>

This generates a source-level HTML report that excludes coverage from logging statements.