They do, but that's not the point GP made. An example how this could fail is if the first branch sets up something that branch two uses. Two tests are written that call branch 1&2 and not call them. 100% code coverage, even the non-happy path was tested.
But in reality, if those branches have any interaction, you would need to write eight test cases for every combination of branches being run and not being run.
Well, again, eight is a lower bound. If the software uses any values beyond the bare minimum (here) of three separate booleans, you're likely to need more.
Take this simplified code:
if condition1:
do_something()
You need one test for code coverage and two for branch coverage, but if there's a bug in the code as written you'll find that you actually need more. Assume that we want to run do_something() when, and only when, condition2 is true.
Now we have four cases:
- condition1 && condition2: do_something() runs, which is correct.
- condition1 && !condition2: do_something() runs, which is incorrect.
- !condition1 && !condition2: do_something() does not run, which is correct.
- !condition1 && condition2: do_something() does not run, which is incorrect.
If you happened to write tests for the first and third of those options, your tests will make it look like your code works, and your (official) coverage metrics will look comprehensive. But because your coverage metrics (in reality) are actually terrible, your code is secretly not working.
The big problem we've just run into is that the number of test cases we need depends on the number of bugs in our code. If the goal of writing tests is to prove that we don't have bugs, this is a terrible result; it means our goal is fundamentally impossible to achieve. We don't know whether we have bugs, so we don't know how many tests we need.
But in reality, if those branches have any interaction, you would need to write eight test cases for every combination of branches being run and not being run.