Post

Sad to see an AI suggest these entries for a [tool.coverage.run] section: omit = tests/*, */__init__.py, */__main__.py, */cli.py, */setup.py, */__pycache__/*, */test_*.py nedbatchelder.com/blog/202008/...

nedbatchelder.comYou should include your tests in coverageThis seems to be a recurring debate: should you measure the coverage of your tests? In my opinion, definitely yes.

26/4/25, 2:41 pm2 reposts10 likes

Mr.Swats

@mrswats.lol

26 Apr 2025

I usually exclude them and then add an extra step in CI to ensure 100% test coverage on tests. I learnt this trick from youtu.be/70T6OxKwxm0

youtu.beyour tests should have 100% coverageYouTube video by anthonywritescode

Ned Batchelder

@nedbat.com

26 Apr 2025

That's good to ensure the tests are 100% even if the product is not. It might be easier to run everything just once and then assess the results: nedbatchelder.com/blog/202111/...

nedbatchelder.comCoverage goalsThere’s a feature request to add a <a href="https://github.com/nedbat/coveragepy/issues/691" rel="external noopener">per-file threshold</a> to coverage.py. I didn’t add the feature, I wrote a proof-of...

Mr.Swats

@mrswats.lol

26 Apr 2025

Yeah, that's what I do. I basically run coverage twice, once for code, once for tests but as different steps in CI.

Ned Batchelder

@nedbat.com

26 Apr 2025

Maybe you don't need to run it twice? github.com/nedbat/cover...

github.comper file coverage threshold · Issue #691 · nedbat/coveragepyuse cases: fail on unexecuted files starting to do unit tests in a big project, overall coverage is low - but we can increase per file coverage more easily