[charlax]

Hey - author of the article here.

Thanks for the detailed answer! I have answered some of your points and some of the points made in the comments below in the article.

The article might have been perceived as more dogmatic than it meant to be. It is actually, I believe, a pretty pragmatic position. I tried to clarify the wording here and there, let me know if you still disagree with the point I'm making.

### 100% test coverage does not mean you're testing everything right.

Absolutely - this point is explicitly stated in this article. I even give an example situation showing how just checking the test coverage leads to missing an important test.

100% test coverage does not make your code invulnerable, and it should evidently not be your only metric. This article is only about the test coverage metric.

### A test suite that covers 80% is pretty good

Absolutely. It is a good number and a good goal for any codebase.

However, what about that remaining 20 %? Why are they not tested? Will it be clear in 2 months why they were not tested? In 6 months? In a year? While it may make perfect sense not to test them, you should be explicit about that decision and keep the reason in the code.

If you don't keep the test coverage _metric_ at 100%, then you leave it up to the code reviewer to challenge your test coverage assumption.

### 100% is a blanket rule that leaves no room for negotiation

Once again, the goal is not to cover 100% of the lines of code - it would be almost impossible. Thanks to `no cover` markers, you can still decide to exclude code from coverage. It actually makes this negotiation explicit in the code, as opposed to implicit during the code review phase coverage.

Consider the example below:

  def toast(bread: str) -> str:
      if toast == "brioche":
          raise ValueError("...")

Let's say you're fixing a bug in this code, and you find out that the `if` branch is not covered. You're left to wonder why. The developer did not have enough time? They decided it was too trivial to need a test?

With an explicit marker, the intent is clear and gives you insight with what is considered appropriate coverage for _this_ codebase:

  def toast(bread: str) -> str:
      if toast == "brioche":  # pragma: no cover, trivial error case
          raise ValueError("...")

### It is not feasible in an old codebase

Right, that's probably the case. However, this is not different from proper testing, monitoring, logging practices. Decide if it's important, then start with something attainable that brings you closer to the goal, and iterate.

Also, if it is not a desirable goal for the codebase, then for sure don't monitor test coverage!

### Enforcing 100% test coverage leads to bad tests

It bears repeating: this is not about testing 100% of the lines; this is about keeping the code coverage metric at 100%. I am not sure how that would lead to bad tests.

Putting too much focus on one particular metric might lead to gaming behavior. That does not mean that no metric you should be enforced. I believe that there isn't enough material and training about what it takes to write good tests. This is beneficial regardless of whether you enforce test coverage. Also, the more you talk about test coverage, the more you iterate and learn about what it takes to write good tests in your language and codebase.

What's sure is that it is straightforward to write bad tests. It takes a lot of skills, experience, and hygiene to write great, maintainable tests. That's a topic for another article.

### 100% coverage only matters for languages without a type checker

No. Sure, a type checker might catch some classes of bugs that would require a test in a language without type checking, but you still need to test correctness (among others).

### You're creating blind spots

Unless you're reviewing your test coverage report after every single commit, leaving explicit markers in the code and keeping the metric at 100% is actually a much safer practice.

When working in code that has been excluded, you'll immediately see the `no cover` marker, perhaps with a comment explaining why the code is excluded. This lets you reconsider the coverage decision.

Any regression in coverage will break the tests.

### You should not exclude code from coverage because of setup cost

This article is not about end-to-end vs. unit testing. I have provided some examples of code that I sometimes exclude from testing, but your mileage may vary.