Hacker News Reader

Comment by GuB-42 | Hacker News Reader

But you probably won't get 99% coverage doing that. Some conditions are just too difficult to get from a higher level, and you still need to take them in consideration: hardware-related problems, race conditions, etc...

I don't consider it a problem, but it is to those who want to see big numbers.

View on HN

I feel like if you're unable to get 99% coverage with that then there's probably some dead code that needs pruned.

As for hardware-related problems and race conditions, testing at a higher level of abstraction seems like it'd help more than it'd hurt - in the former case ensuring graceful handling as part of the tests, and in the latter case making the race conditions more likely to hit (and hopefully fix).

I see the OP as talking about “integration” style tests (say testing against an api) and not being able to capture all of the OS and similar edge case errors in the test. I do think this is a hard problem, particularly if you don’t design for it from the outset.

It’s a bit of the old classic “reading from the file never returns an ‘access denied’ error, until it does”. There’s ways and means, but let’s not pretend this is simple.

You don't need 99% coverage. You just need enough coverage to be able to refactor the thing without breaking it.

I bet the reason they aim for 99% coverage is because they're using Python on JavaScript for some complex software, which means they've roped themselves into being their own compiler. Without all that test coverage, all the bugs are surprise runtime bugs, and the tests take the "surprise" part out.

Reply on news.ycombinator.com