“What is BDD?” is a question that’s been doing the rounds lately within the altnetgroup and devbookclub. There’s a great deal of mysticism surrounding it as if it were some exclusive members club. I’m going to slay some of the myths and tell you what BDD really is.
Myth 1: BDD requires a framework or tool
You don’t need to use MSpec, RSpec, Cucumber, etc to practice BDD. Sure they can help but they are not a precursor to being a practitioner of BDD. You don’t even have to write your tests within a certain construct such as Given-When-Then.
Myth 2: BDD requires UAT
User Acceptance Testing is a great concept but is one of those practices that only the elite working with an exceptional client get to do in real life. If you have UAT as part of your process, all power to you, but that’s all it is, part of your process. It is not part of BDD. It is merely coincidental that BDD style tests are the best way to express your acceptance tests.
Myth 3: BDD has to be done top-down
It is easier to approach BDD in a top down manner. But much like its easier to put your underwear on first, that doesn’t work for everyone in every situation. Just ask Superman. The proponents of BDD often state things in a radical fashion due to a fear of BDD being thrown in the same pot as TDD. That doesn’t mean that every time they say “you must” they actually mean it.
So what is BDD?
At its core, BDD is TDD done with a specific mindset; testing the intent of the system rather than testing a particular piece of code. The difference is subtle but the effects are large. There’s an entire discipline dedicated to the power of semantics after all.
It is the difference between “when I add a new post to my blog, the new post shows up on my homepage” and “calling the create new post method on the blog controller saves a new post and the new post is passed to the homepage view when the home controller’s index action is called”. Both sentences describe the same code, the BDD style signals the intent and is decoupled from the implementation. The non-BDD style describes what the code is doing almost line for line. The decoupling of the tests from the implementation is where the largest benefit of BDD comes from. Your tests will be less brittle making refactoring easier, perhaps even fun, making your code more malleable.
The myths aren’t completely unfounded, using constructs such as Given-When-Then helps enforce the required mindset. Frameworks such as MSpec, RSpec, Cucumber or even a bespoke one help you write tests within that construct. Working from the top-down helps you work from the behaviour of the user interface down to the behaviour of the data access. UAT helps you drive the behaviour of the system from the requirements of the client.
That’s all these things do though, help you develop in the BDD style. You can still write your code in a non-BDD style using all these frameworks, tools and processes, just as you can develop in the BDD style using none of them.