BDD Toolbox: Happy Path/Sad Path

BDD Toolbox is an ongoing set of posts to give you tools to aid in the process of doing Behavior Driven Development well. Today we’ll take a look at Happy Path/Sad Path – a tool to ensure you’ve captured success and failure cases for all of your scenarios.

Happy Path/Sad Path is a way of looking for meaningful examples in the course of crafting our specifications. It works on the idea that for every success case there is often a failure case as well. Before we dive further into Happy Path / Sad Path, let’s revisit one of the key practices of BDD so that we understand why this is an important tool to master.

Not Tested = Not Built

BDD is an automated acceptance testing framework, but it is also a set of disciplines that were learned from the best practices of Test Driven Development. One of the great disciplines of working within BDD is that you only build what you need to make a failing test pass. This is important for a number of reasons. By always starting with a failing test, we know that any code we add will have a corresponding test that ensures it stays correct. When we run the test suite later, it will tell us that everything is behaving as we previously decided was correct. Additionally, working with a failing test means that we’re focused only on building things of real business value. It’s easy to fall into traps where you think something orthogonal is vital*. Because BDD is based around acceptance testing, we want to know that if all our tests passed, the system truly is in an acceptable state.

This makes it essential to capture all relevant scenarios in our feature files. While everyone on the team should feel empowered to stop the process at any time and ask if something seems missing, the best place to capture scenarios is at the 3 Amigos meeting, because all stakeholders are present. This is where Happy Path/Sad Path becomes a very useful tool.

Two Sides of The Coin

When you’re looking at a specific story or feature, you’ll nearly always have one set of rules if it goes right, and a set of strategies for dealing with something that goes wrong. For instance, you have a login form. The user can give you a valid username and password – Happy Path. Or they can mistype their password – Sad Path. By knowing that these two sides exist to nearly every requirement, you can be actively looking for them when capturing scenarios. Ask yourself when putting together a scenario if there’s an error case (or cases) that should also be handled. There will often be multiple ways for something to go wrong, so don’t make the mistake of thinking you are only looking for a single failure. The key to success is getting in the mindset of asking “can you give me some examples of where this can go wrong?” whenever you see a Happy Path in your specifications.

Smoothing the Path

One of the great advantages to Happy Path/Sad Path is that it helps you catch edge cases up front. A huge benefit of doing BDD well is being able to know your edge cases before you start building. Every seasoned engineer can cite a project that was humming along smoothly when all of a sudden they discovered a requirement that broke some base assumptions they had built into the product. Usually the only way out is a huge refactor that no one accounted for in the timeline. The better you can get at avoiding those late-discovered edge cases, the more smoothly and predictably development will run.

*Incidentally, I first learned Happy Path/Sad Path from Aslak Hellesøy, the creator of Cucumber. During a class I took with him, he caught me writing code that didn’t make a failing test pass and hammered this discipline home. So I understand the engineer impulse to build it “because we know we’ll need it,” but in the end it’s much wiser to stop and ask your team if this should be added to your tests than to simply go and build it.