Although
When white-box testing an Erlang application, it is useful to
be able to measure the code coverage of the test.
To specify the modules to be included in the code coverage test, provide a cover specification file. With this file you can point out specific modules or specify directories containing modules to be included in the analysis. You can also specify modules to be excluded from the analysis.
If you are testing a distributed Erlang application, it is
likely that code you want included in the code coverage analysis
gets executed on another Erlang node than the one
In the cover specification file you can also specify your
required level of the code coverage analysis;
You can choose to export and import code coverage data between
tests. If you specify the name of an export file in the cover
specification file,
To activate the code coverage support, specify the name of the cover
specification file as you start
$ ct_run -dir $TESTOBJS/db -cover $TESTOBJS/db/config/db.coverspec
You can also pass the cover specification file name in a
call to
You can also enable code coverage in your test specifications (see section
By default, the Cover tool is automatically stopped when the
tests are completed. This causes the original (non-cover
compiled) modules to be loaded back into the test node. If a
process at this point still runs old code of any of the
modules that are cover compiled, meaning that it has not done
any fully qualified function call after the cover compilation,
the process is killed. To avoid this, set the value of option
The option can be set by using flag
The following terms are allowed in a cover specification file:
%% List of Nodes on which cover will be active during test. %% Nodes = [atom()] {nodes, Nodes}. %% Files with previously exported cover data to include in analysis. %% CoverDataFiles = [string()] {import, CoverDataFiles}. %% Cover data file to export from this session. %% CoverDataFile = string() {export, CoverDataFile}. %% Cover analysis level. %% Level = details | overview {level, Level}. %% Directories to include in cover. %% Dirs = [string()] {incl_dirs, Dirs}. %% Directories, including subdirectories, to include. {incl_dirs_r, Dirs}. %% Specific modules to include in cover. %% Mods = [atom()] {incl_mods, Mods}. %% Directories to exclude in cover. {excl_dirs, Dirs}. %% Directories, including subdirectories, to exclude. {excl_dirs_r, Dirs}. %% Specific modules to exclude in cover. {excl_mods, Mods}. %% Cross cover compilation %% Tag = atom(), an identifier for a test run %% Mod = [atom()], modules to compile for accumulated analysis {cross,[{Tag,Mods}]}.
The terms
Directories containing Erlang modules to be included in a code
coverage test must exist in the code server path. Otherwise,
the Cover tool fails to recompile the modules. It is not sufficient to
specify these directories in the cover specification file for
The cross cover mechanism allows cover analysis of modules across multiple tests. It is useful if some code, for example, a library module, is used by many different tests and the accumulated cover result is desirable.
This can also be achieved in a more customized way by
using parameter
The mechanism is easiest explained by an example:
Assume that there are two systems,
s1.cover:
{incl_mods,[m1]}.
When analysing code coverage, the result for
Now, imagine that as
s2.cover:
{incl_mods,[m1]}.
This gives an entry for
If instead the cover specification for
s2.cover:
{cross,[{s1,[m1]}]}.
Then
The call to the analyze function must be as follows:
ct_cover:cross_cover_analyse(Level, [{s1,S1LogDir},{s2,S2LogDir}]).
Here,
Notice the tags
To view the result of a code coverage test, click the button labeled "COVER LOG" in the top-level index page for the test run.
Before Erlang/OTP 17.1, if your test run consisted of multiple tests, cover would be started and stopped for each test within the test run. Separate logs would be available through the "Coverage log" link on the test suite result pages. These links are still available, but now they all point to the same page as the button on the top-level index page. The log contains the accumulated results for the complete test run. For details about this change, see the release notes.
The button takes you to the code coverage overview page. If you have successfully performed a detailed coverage analysis, links to each individual module coverage page are found here.
If cross cover analysis is performed, and there are accumulated coverage results for the current test, the link "Coverdata collected over all tests" takes you to these results.