Hi, I'm Ben 🐚

Dithered image of a dog under blankets

I while back, I made a few contributions to the Narwhal’s project, mostly helping get Dask support up and running. It was an awesome experience overall, not in small part because the lead maintainer Marco puts high five gifs of cats on pretty much every pull-request. One thing I hadn’t really seen before, was actual 100% coverage across the full codebase.

I’ve heard a lot of people advocate against 100% coverage, mostly on the principle that it doesn’t measure how good your tests are, or how much they cover the important edge cases that your code might hit. That’s all true of course, but after putting 100% coverage in place on some work and personal based projects, I’m completely sold on it- here’s why.

Having 100% coverage offloads the concept of “this new feature should have a test” to the integration checks, because it’s easy to put a check in place that tests have full coverage. This is a really nice bonus for code reviews, because telling someone to write a test is important, but it isn’t a very interesting comment, or good use of your time. In the same way that linters like Ruff and Black mean you don’t need to comment on code-style, having a coverage check means you can skip saying “oh you forgot to write a test” and focus on the code, or the quality of the actual test written.

The open question is really how to get there on a project that doesn’t have full coverage yet, short of having a big push where you get to 100% in a few PRs (which may not be realistic), I’ve found what’s really worked has been:

  1. Add in a check on PRs that coverage doesn’t drop below the level it’s currently at
  2. Periodically bump up that level as coverage increases
  3. Don’t be afraid to make use of # pragma: no cover comments

The first two are handy for getting to 100% coverage, but I think the third one is a real winner culturally. Trying to argue for 100% coverage inevitably hits push back of the kind that “this specific bit doesn’t need coverage”. I think conciously not testing a part of code is much less risky than just accidentally not having tests for things. Being a little charitable in what has # pragma: no cover against it, is a great way to get coverage to a point where every line of code:

That won’t guarantee you no bugs overnight, but it’ll catch accidental test lapses.

And it’ll save you nagging your team to write tests.

For that last point alone, it’s worth it in my book.


Photo by Sdf Rahbar on Unsplash