Hacker News new | ask | show | jobs
by AtlasBarfed 1808 days ago
harkens back to the early obsession with "100% code coverage" and java robots were coding tests on bean getters/accessors.

100% code coverage was a bad breadth-first metric when unit tests should be depth based on many variant inputs. Also, "100% code coverage" ignores the principle that80% of execution is in 20% of the code/loops, so that stuff should get more attention than worrying about every single line being unit tested.

Well, unless you were in some fantastical organization of unicorn programmers that had an infinite testing budget and schedule...

1 comments

A good exercise is to get 100% coverage for anything that uses ByteArrayInput/OutputStreams. The language enforces handling IOException for a bunch of methods that could throw one for a generic stream but never for a ByteArrayStream.