A branch is the outcome of a decision, so branch coverage simply measures which decision outcomes have been tested. This sounds great because it takes a more in-depth view of the source code than simple statement coverage, but branch coverage can also leave you wanting more.

Determining the number of branches in a method is easy. Boolean decisions obviously have two outcomes, true and false, whereas switches have one outcome for each case and don’t forget the default case! The total number of decision outcomes in a method is therefore equal to the number of branches that need to be covered plus the entry branch in the method (after all, even methods with straight-line code have one branch).

In the example above, return Input () has seven branches—three true, three false, and one invisible branch for the method entry. You can cover the six true and false branches with two test cases:

Both tests verify the requirement (output equals input) and they generate 100 percent branch coverage. But, even with 100 percent branch coverage, the tests missed finding the bug. And again, the manager may believe that testing is complete and that this method is ready for production.

A savvy developer recognizes that you’re missing some of the possible paths through the method under test. The example above hasn’t tested the TRUE-FALSE-TRUE or FALSE-TRUE-TRUE paths, and you can check those by adding two more tests.

There are only three decisions in this method, so testing all eight possible paths is easy. For methods that contain more decisions, though, the number of possible paths increases exponentially. For example, a method with only ten Boolean decisions has 1024 possible paths. Good luck with that one!

So, achieving 100 percent statement and 100 percent branch coverage may not be adequate, and testing every possible path exhaustively is probably not feasible for a complex method either. What’s the alternative? Enter basis path coverage.