Discussion: make 100% test coverage part of automated build checks?

[AartGoossens]

No description provided.

[piotr-kubica]

A very high test coverage is a good idea, but I think that a 100% test coverage is a bad idea. There will be code that introduces almost no complexity. Do you want to test them?

[AartGoossens]

Thanks for weighing in @piotr-kubica!
The main reason for me to aim for 100% test coverage is reducing the risk that merging a PR breaks something. Reducing that risk minimizes the overhead of reviewing the PR (if we think a new feature adds value to the library and doesn't break anything we can just merge it without the reviewer having to understand the new code completely) and also enables us to use a single branch git model where every PR is merged to master and will be included in the next release (the single branch model itself is also a method for reducing overhead for open source maintainers).
Although 100% test coverage doesn't ensure that nothing can fail, it does reduce the risk. Also, I think that a library like this is perfectly suited for high test coverage because most of the logic is in pure functions that are quite easy to unittest.
For me the only drawback in aiming for 100% test coverage is the time that's needed to create the unittests. And I think that's a small sacrifice to make.

What would be your arguments to avoid enforcing 100% test coverage?

[piotr-kubica]

It's a long topic I guess
https://stackoverflow.com/questions/1475520/unit-testing-code-coverage-do-you-have-100-coverage

[AartGoossens]

Haha yes it is.
I think I'd like to try enforcing 100% coverage for a while to see how it goes but we should be reasonable about it: if it's too much of an effort, introduces other complexities or doesn't give us enough benefits we should step away from it quickly again.