Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (088f491) 95.27% compared to head (d025c7c) 95.27%.

@@           Coverage Diff           @@
##             main     #883   +/-   ##
=======================================
  Coverage   95.27%   95.27%           
=======================================
  Files          54       54           
  Lines        4525     4525           
  Branches      893      893           
=======================================
  Hits         4311     4311           
  Misses        130      130           
  Partials       84       84           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Instead of using an end-to-end test case with a file containing over 10k lines, it might be sufficient to just test this on the gcov parser level and add an example to the parser's doctests. Something like:

>>> _parse_line("    %%%%%:12345-block  0")  # see https://github.com/gcovr/gcovr/issues/882
_BlockLine(hits=0, lineno=12345, blockno=0, extra_info=NONE)

As a general point, the gcovr test suite is fairly detailed but also extremely slow, and maintaining the "golden master" files is tedious (especially for XML and HTML formats). Wherever we can check something via a cheap unit test, we should prefer that.

One thing I've wanted to do (when I have the energy, so probably never) would be to review the test suite, remove tests for formats that aren't needed (so probably preferring JSON tests over HTML tests when testing reader functionality, preferring JSON inputs over running gcov when testing writer-side functionality), porting Makefiles to Python test modules to reduce re-building and process spawning overhead, and maybe even finding a way to use pytest-xdist for parallelization. Once there are fewer golden master files, it would also be easier to drop ancient GCC versions.

Instead of using an end-to-end test case with a file containing over 10k lines, it might be sufficient to just test this on the gcov parser level and add an example to the parser's doctests. Something like:

>>> _parse_line("    %%%%%:12345-block  0")  # see https://github.com/gcovr/gcovr/issues/882
_BlockLine(hits=0, lineno=12345, blockno=0, extra_info=NONE)

I'll update this.

As a general point, the gcovr test suite is fairly detailed but also extremely slow, and maintaining the "golden master" files is tedious (especially for XML and HTML formats). Wherever we can check something via a cheap unit test, we should prefer that.

One thing I've wanted to do (when I have the energy, so probably never) would be to review the test suite, remove tests for formats that aren't needed (so probably preferring JSON tests over HTML tests when testing reader functionality, preferring JSON inputs over running gcov when testing writer-side functionality), porting Makefiles to Python test modules to reduce re-building and process spawning overhead, and maybe even finding a way to use pytest-xdist for parallelization. Once there are fewer golden master files, it would also be easier to drop ancient GCC versions.

In this case we should also consider to remove the makefiles and use a python based test configuration. I was also thinking about this change.