BDD: Just tell me what the eff it is!

Here's my big problem with BDD...on first blush the only thing you can see of it are the tools used in it for testing and a bunch of acronyms and buzzwords.  You get all these testing frameworks to try to write natural language tests geared to output something your stakeholder can both read and understand.  For a long time, the question still stood for me; what is BDD?  How do you do BDD?  Sure, my tests were now human readable but it still hadn't added up.

For those that don't understand what BDD is and even those that do, I want to walk you through what I've learned over the last year.  I want to give you an alternative narrative to the stuffy version on wikipedia and the dated top ranked Google results which offer breadcrumbs to understanding but didn't give me the clarity I was looking for.

Let's look at the two line summary Dan North gave last year,

BDD is a second-generation, outside-in, pull- based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters.

Get it?  Neither did I when I first read it.  After doing a lot of research, investigation and experimentation I finally get it.  Now that I do, that two line definition is an excellent summary.  There's a lot of information packed into those sentences.  We won't try to drill into all of that here.  Let's start with the simple building blocks of the BDD process.

It starts with a story

BDD is firmly rooted in the agile universe.  It relies on a lot of the mechanisms and practices you find in agile processes.  The first and most important is the practice of capturing user requirements as stories.  I'm not going to spend time in this post defining what a story is but let's just use an example we can refer to.

In order to build readership of the blog
As a blog reader
I want to leave comments

This is the first step in BDD, the first tangible piece of the process.  Your stakeholder(s) and your agile group develop stories.

Create examples/scenarios

You have your story.  Take that story and imagine (realistic) scenarios of it in practice.  Who it is that generates the scenarios may be multiple people.  Your scenarios are your acceptance criteria.  They tell you when the story is done.

Here are some samples of scenarios based on the above story.  (Remember, for this story, we're in the context of a reader of the blog and their desire to leave comments.)  The scenarios are written using the Given-When-Then format for describing scenarios.

Given a blog entry
When I write a comment
And I submit the comment
Then I should see my comment under the blog post

Given a blog entry
And the blog entry is no longer accepting comments
When I view the blog entry
Then I should not be allowed to write a comment

You can see how there would be numerous scenarios and contexts of users of your application.  When generating your scenarios, you must take them all into account.

You're just about to write code but...AUTOMATION!

Any good development environment should be as automated as (in)humanly as possible.  With a few quick commands/scripts you should be able to build your app, build your DB (if you have one), execute tests, deploy the app, and run it.  The more you have to do manually the harder this whole thing is.

Also, you should be able to run this in isolation on your workstation, if possible.  If your app is sharing a DB with 5 other workstations in your department, chances are you're going to have collisions.  You won't be able to make predictable tests and you'll be stepping on each others' toes.

When you write your code you want to be continuously running tests.  This should be a push-button activity that does not derail you for several minutes.  If it is then analyze what it is that you're doing and see if you can find ways to streamline it.  Either through tooling or through eliminating deficiencies in your testing strategy.

Outside-in: It's time to TDD

In BDD, we do things outside-in.  Meaning, you start at the level of the user's interaction with your application and then you build downwards.  It's a huge shift for a lot of people.  I haven't been doing it for very long but it's not a huge departure if you were already doing TDD.  Most of my difficulty was just learning how to automate UI interactions.

Here is where the rubber (finally) meets the road.  You have a story, you have some scenarios of your story that crystallize your acceptance criteria, and you have an automated development environment that allows you to build and test your app rapidly.

Using the story and scenarios from this blog post, we can write our first lines of code.  But...I'm not going to do that here.  I have a separate blog post (it certainly deserves its own) coming that will walk through the TDD process under the BDD umbrella.  I'll update this post to refer to it once it's done.

In summary

1. Write user stories
2. Create scenarios based on the stories
3. TDD those stories starting at the top level of your application (typically a UI) and keep developing downwards until it's functionally complete

Yes, that's seriously it.  There are methodologies, practices and tools that go inside of it but, at its simplest, that's all you're really doing.  If you're reading about BDD then I have no doubt that you're already aware of most of these topics anyways. 

The mystical cloak of BDD has now been removed!

DISCLAIMER:  This was meant to be a high level, entry level explanation of BDD because I have rarely seen it simplified.  Most information I've found online, the explanation seems to be a deep dive into how to write stories, stakeholder interaction, how DDD dictates the ubiquitous language, how it's the natural evolution of TDD (without ever showing you how!), and a variety of other entirely relevant information.  The problem is that there's a lot of cognitive overload.

In other words, for BDD enthusiasts, or developers in general because we like to be intellectual, don't dog me out and poke holes in my examples.  It's horribly contrived, I readily admit I am still learning these concepts and I don't believe anything I've written is incredibly misleading.

Analysis and Investigation on Outside-In Development

BDD has a variety of testing tools surrounding it in a number of languages. Since I'm primarily in the .NET world (looking to expand that soon), I've dabbled with MSpec and had a lot of fun/success in creating descriptive tests that spoke the language of the business and communicated value. That was my first experiment in the world of domain drive design in an agile process.

The one thing these tools have in common is that they promote outside-in development. In BDD that literally means starting at the touch point with the consumer/customer/stakeholder. For most applications, that's a GUI of some sort but for others it may be a web service or something similar.

I've seen outside-in development go by a couple names like story driven development or acceptance test driven development. Unless I'm mistaken, they're both trying to achieve the same goal. What outside-in development is trying to do is make the software customer-oriented not unlike the agile processes that fit with this thinking. You start building the software from the customer's point of view based on their specification of it (usually as a story). Coupled with agile, you're doing something along the lines of rapid prototyping (with a bit more discipline). It's also keeping you focused on what the customer wants. It discourages gold plating and extra work that are typically waste.

<tangent>

I don't like to say gold plating because I know there are those developers that think that discouraging gold plating is like discouraging free thought and creativity. I would disagree. The hard pill for us to swallow is that what we perceive to be a "better way to do things" is not from the perspective of the actual consumers of the application. They may have no use for the bells and whistles that we believe to be productivity boosters. What it may be doing instead is creating excess inventory that costs money but has no ROI.

However, if you're in an agile process (or even if you're not), don't despair! Agile, by its very nature, relies on high-bandwidth communication. Reach out to the customer and communicate your creative thoughts and ideas. They will rely on your expertise in this arena and most times accept your recommendations. But, just remember, if they don't find use for your widget/tool/interface then don't do it (at least on company time :-P)!

</tangent>

Sooooo this is what I've understood so far. I am by no means an expert on outside-in development and I'm still trying to understand the practice. In the past, I've worked from the application logic and worked my way downwards. I haven't done it from the UI down which is certainly an interesting experiment. I'm also coming to find that I haven't done nearly enough acceptance/functional testing in my travels.

I plan on following up this post with my first attempt at doing outside-in development. I need to find a good book on it. I'm pretty sure the RSpec Book is probably what I'm looking for but any recommendations are appreciated. In the meantime, I've just been reading blogs, articles and comments. One such blog I ran into has a tremendous amount of insight into testing and offers good information to get you started on writing acceptance tests using ASP.NET MVC and some other tools and frameworks. Check out Steve Sanderson's blog to get some really great information.