[captbaritone]

Post author here. That’s a great framing! That means that, in theory, an enforced 100% code coverage would catch these issues as well, which I’m inclined to believe!

[thomasrockhu]

Tom from Codecov here.

I'm a huge proponent that branch coverage is way more important than just statement coverage, because as you mentioned, it's way easier to miss these types of bugs just by getting 100% statement coverage.

[_a_a_a_]

I think I am unclear what you mean by branch coverage. I assumed it means ensuring that every 'then' and 'else' branch is taken? But if so, that means every statement must get covered, right?

Put another way, you can only get 100% statement coverage if every 'then' and 'else' branch is taken, so 100% statement coverage and 100% branch coverage seems to be saying the same thing I think a misunderstanding you, an explanation would be helpful, thanks.

[addaon]

Branch coverage is also known as decision coverage. Essentially, it means coverage of every machine code instruction in the generated binary. This includes every statement in every 'then' and 'else' (which would be statement coverage), but also includes decisions that are sub-expressions and not statements. Consider:

    if (foo() || bar()) {
      a();
    } else {
      b();
    }

Statement coverage says that a test must cover the lines of code (or statements) `if (foo() || bar())`, `a()`, and `b()`. But if `foo()` is tautological then the || short circuits, and all of your tests can pass, with 100% statement coverage, even if `bar()` causes the sun to go nova. With 100% decision coverage, you must have a test case that causes `foo()` to return false, so that you can test the behavior when `bar()` both returns true and returns false.

Edit: The above isn't a correct example, because statement coverage will not hit `b()` if `foo()` is tautological. Still, you can see the point -- there's a difference between decision coverage and statement coverage.