18 ms·

Although coverage reports are misleading, 100% coverage means that you passed through every line of code, that's it. You don't know if you covered edge cases,

• StevenWaterman 6y ago
  You're right about edge cases in terms of input values, and right about issues with concurrency, but many of the issues you mention are solved by changing your metric. Branch-level coverage tells you what percentage of codepaths are covered. In other words, it would report 50% coverage for: if a: print "a yes" else: print "a no" if b: print "b yes" else: print "b no" test 1: a = false, b = false test 2: a = true, b = true
• mumblemumble 6y ago
  > every line of code, that's it Yes. And it's worth noting what's left out of that. Passing through every line of code is not the same thing as following all paths through the code. Here's a sampling of code features where that distinction is particularly important: - successive if-statements - switch statements with fallthrough - loops - mutable variables with a large influence The first two are because {{a}, {b}} ≠ {{a, b}}. By that last one, I mean both mutable variables with a large scope, and mutable variables within objects that have a large scope. That's probably the trickiest thing, because, in the presence of mutability like that, it's not just which lines of code were executed that matters, it's also the order in which they were executed. That doesn't strike me as a pretty picture. Overall, it implies that automated code coverage metrics are the least useful in the kinds of codebases where they are most desirable.