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.
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:
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.