gcovr 3.4
5 min by Lukas Atkinson Projects (3) Python (9)

I am excited to announce that gcovr 3.4 has been released!

This release represents over a year of accumulated bug fixes. Support for Windows and for Python 3 has been greatly improved. There are also a number of quality improvements behind the scenes.

Gcovr is a command line tool that uses gcov to produce code coverage reports as text summaries, detailed HTML reports, or Cobertura-compatible XML. I works with the GCC and Clang compilers.

You can pip install gcovr from PyPI, read the overview on GitHub, or read the user guide.

Changelog highlights

Breaking changes:

  • Supported Python versions are 2.7+ and 3.4+. Python 2.6 is still supported on a best-effort basis, but might not receive new features.

  • The behaviour of filters may have changed subtly.

New features:

  • Not every source code uses ASCII! With the new --html-encoding option, you can prevent garbled reports.

  • Want to fail your build process if coverage is too low? Specify a limit with the --fail-under-line and --fail-under-branch options!

  • Tired of writing gcovr -r .? If the -r/--root option is not specified explicitly, the current directory . will be assumed.

  • If a file contains no branches, and none are covered, is that 0% or 100% coverage? Gcovr leaves that Zen koan to someone else, and reports these cases as --%.

  • Gcovr is now better at guessing the location of your source files when using existing gcov files with the --use-gcov-files option.

Bug fixes:

  • gcovr now supports version 4 of the Cobertura XML. This makes it possible again to use these reports with Team Foundation Server (TFS) and Visual Studio Team Services (VSTS).

  • HTML reports were fixed for Python 3.

  • HTML reports were fixed for Windows.

  • Filters work with absolute paths, as they should (Linux/Unix only).

  • Filters work on Windows.

Behind the Scenes:

  • Automated tests are now also executed on Windows, thanks to AppVeyor.

  • HTML reports are now part of the automated test suite.

If you encounter any bugs, please report an issue on GitHub.

Future Plans

Now that a backlog of bug fixes and improvements has been worked through, we can focus on some internal changes. The following is a number of long-term ideas and a vision for gcovr. It should not be understood as a roadmap or promises for future features.

  • Right now, gcovr is a large singe script that has … organically grown. By dividing it into Python modules, it will become easier to maintain. This may allow other programs to interface programmatically with gcovr, instead of using the command line interface.

  • Once the data flow has become clearer, it can hopefully be simplified. We can get rid of global variables and move to smaller, more obvious functions. These functions can then be unit-tested, instead of relying on slow integration tests.

  • Filters are a bit of a mess. They don't quite work on Windows, and work surprisingly on Linux. Figuring out how filters should behave and implementing that behaviour uniformly is a big, but important chunk of work.

  • HTML reports can be provided by Jinja templates. Currently, they are templated in an ad-hoc manner.

    Simplified HTML generation may allow additional features such as per-directory sub-reports.

  • XML reports can be made more performant. The XML data describes the coverage for all lines in a project. For large projects, this requires too much memory. Using either a more efficient DOM representation or a streaming output method will address this.

  • Tests with GCC 7 and Clang are important. Currently, the test suite assumes GCC 5.

  • The documentation needs to cover the various options in more detail. Moving to Sphinx will make it simpler to manage these documents.

  • Even though gcovr is a code coverage tool, we don't collect coverage for gcovr. That is a bit embarassing^^

    Update (2018-02-15): already implemented by mayeut, see #216.

  • A new machine readable output format (such as JSON) will make gcovr easier to script. E.g. a coverage summary could be extracted from this output in order to generate coverage badges.

  • For the HTML report, optionally placing CSS in a separate file will let gcovr play nicer with the Jenkins Content-Security-Policy.

  • Source file encodings continue to cause problems. Adding a source file encoding option and continuing despite decoding errors (e.g. because different files have different encodings) will make gcovr more useful.

  • Clarified source file heuristics. Gcovr tries to guess the path of the source file from the coverage data. This is highly dependent on the build process, and doesn't always work correctly. Figuring out sensible heuristics and documenting them clearly will prevent a common source of user errors.

Phew, that's a long list! If you would like to help out, start by looking at our contribution guidelines on GitHub. Before starting a PR for a new feature or big change, please open an issue first so that the proposed change can be discussed.