3 ms·
I've occasionally been lulled into a false sense of security by the difference between "every line is run" and "the function is fully tested". On the other han
by saalweachter 5y ago
I've occasionally been lulled into a false sense of security by the difference between "every line is run" and "the function is fully tested".
On the other hand, even if I'm half-assing the unit tests, and implementing the bare minimum necessary to reach whatever arbitrary coverage% is being sought ... I still find bugs, bugs that almost certainly would have a real impact in production, even if I already ran an end-to-end test and was pretty sure it was working fine[*]. Not every time I write tests, but often enough to feel like it pays for all of the time "wasted".
So even if coverage metrics maybe arbitrary, I don't really begrudge having to meet them. And honestly, once you're forced to start writing the tests just for coverage, it isn't that much extra work to make them a little more comprehensive than the floor set by coverage.
[*] Honestly I'm shocked at how well buggy software works, for the most part.
- AlexCoventry 5y agoThat's my experience, too. Coverage isn't a good proxy for test quality, for sure, but it's a good proxy for having looked carefully at every line. I think coverage testing is useful as long as you're prepared to throw those tests away when you refactor, or at least ignore them during refactoring.