Blog of Rob Galanakis (@robgalanakis)

Including test files in coverage reports

We’ve finally gotten our test coverage reports published to an accessible place and I’ve been wondering whether including test files as part of the coverage report is generally preferable to excluding them.

Initially I thought they should be excluded- after all, it’s your ‘real’ code people are generally worried about- but now I’m not so sure. You should probably make sure your test files are actually run and covered, as once you have a large amount of tests that often bend in various ways, it isn’t always a given. And actually that’s just the case  we were in today, we have tests that are still not runnable on our CI server, but the report doesn’t show which ones.

Not to mention having your test source easily browseable in the form of a coverage report, which is easier for test-curious people to browse than a source depot.

I think I’m going to re-include tests in the report, despite it skewing our coverage percentage (favorably :)). But I’m really curious if there’s accepted practice or good reasons either way I haven’t thought of.

One thought on “Including test files in coverage reports

  1. Nick Coghlan says:

    It’s worth including them for the reasons you state: if particular tests aren’t being executed, you want to know that directly rather than trying to decipher the cause of low coverage numbers in supposedly tested code.

    It also helps you detect dead support code.

Leave a Reply