BCDD — Branch Coverage Driven Development

Introducing a game that’s guaranteed to make your code better and work — more rewarding. Instantly. Participating in it you’ll learn more and more about your code every hour. And every time you’ll check-in to see your score you’ll be reminded that your code — absolutely, unquestionably, categorically — is simply brilliant. Lean, reliable and correct. Fucking A!

If you are a developer, I assume that you already incorporate some form of testing in your workflow. Whether ad-hoc scaffolds you tear down as you move on or TDD practised across your team with coverage enforced in your CD pipeline, tests are an indispensable part of development process. And now, with this simple trick, you can make them fun on their own part.

Find a test coverage tracking tool that fits your build, make sure it’s set up to generate reports that include your code and (and this is crucial) branch coverage in one view during every build, and make it your personal goal to attain 100% branch coverage for every block of code you write.

And … that’s it. (Managers hate me for this simple, single, trick!)

Tongue-in-cheek aside, it really is that simple yet incredibly rewarding. Having an ability to quickly, with a glance, see which parts of your code might have been left out by tests will give you:

• Heads up on dead code. If nobody calls it, delete it. Guaranteed not to introduce any new bugs and save you time in one keystroke*. And if it really shouldn’t be dead, congratulations. You just discovered a piece of code that doesn’t work quite like you thought it does.
• Pointers to suspicious code. (“Wait, the order is actually created in the database via this path? WTF?!”) Tests that only verify behaviour have a good chance of passing by accident, especially in large codebases. Been there, done that, got a t-shirt three sizes too small.
• A daily reminder of what your tests are testing and what they aren’t. Can you remember what that test you wrote two weeks ago is actually testing? Even if you look at it? What about these 200 more? Systems change, yet we are rarely motivated to go back and revisit old tests. They grow stale, even if continue to report impressive coverage numbers.
• Defensive mindset. Have you tested all possible inputs? Are your checks for correctness and error paths ever touched? Cover them and you’ll know for sure. Introduce and touch a few more while you are at it! You will discover that your original assumptions needed a small tweak, you‘ll get new ideas on how to handle things better, those checks really were superfluous and should have been consolidated above and so on…
• Small, incremental, rewards for every hour of work. Even if you are still far from finishing any particular piece of work just fire up the tests and have a nice confirmation that you are getting there. Just be careful, the whole social gaming industry is based on such bite sized chunks of behaviour reinforcement rewards. Don’t get addicted.

As simple as it may sound — a visual reminder of the fact that there are parts of your code that aren’t called will motivate you to improve on it. Will let you spot the crucial blocks of code that really need to be covered. Motivate that 5 minute lunchtime refactoring to isolate something from the rest of the code and exercise separately.

Don’t treat testing as safety net for when refactoring goes wrong (or manager grumbles about it dipping below a magical number). With a small tweak to your build, testing process can become an incredibly useful tool that will tell you what your code is actually up to.

Try it, it’s brilliant. All the cool guys do it**.

* Or forcing a developer analysing it to spend hours deliberating if it’s really just some dead code or a vital, yet well beyond his experience, obscure, edge case.

** I made it up, of course.