software solutions / project leadership / agile coaching and training

Why Behavior Driven Development is good

Posted on July 25, 2008

On my current project I was introduced to Behavior Driven Development. When I first heard of BDD, I thought, “Is BDD any more than a new way to name your test methods? What’s the big deal?”

Here’s a simple unit test class that I might have written in the past:

[TestClass]
public class EmployeeTests
{
[TestMethod]
public void LastNameRequiredTest()
{
}

[TestMethod]
public void BirthDateCannotBeInFutureTest()
{
}

[TestMethod]
public void LastWidgetDateTest()
{
}
}

When I would write a test like this, the goal was to make sure that the code that I had written was working (I normally wasn’t doing TDD when writing these tests). Now there’s nothing wrong with that, let’s say that my code coverage was good, and things are good.

A BDD-style set of tests would look more like this:

[TestClass]
public class Given_an_Employee
{
[Setup]
protected override void Before_each_test()
{
}
}

[TestClass]
public class When_validating_an_Employee : Given_an_Employee
{
[TestMethod]
public void Then_the_LastName_is_required()
{
}

[TestMethod]
public void Then_the_BirthDate_cannot_be_in_the_future()
{
}
}

[TestClass]
public void When_an_Employee_makes_a_widget : Given_an_Employee
{
[TestMethod]
public void Then_the_LastWidgetDate_should_be_set_to_today()
{
}
}

Whoa, what’s with all the classes and underscores and all that! Put your preconceived notions aside and let me explain. :)

First, let me explain why TDD is good. I think that these points illustrate this best.

1. The developer starts writing unit tests around their code using a test framework like JUnit or NUnit.
2. As the body of tests increases the developer begins to enjoy a strongly increased sense of confidence in their work.
3. At some point the developer has the insight (or is shown) that writing the tests before writing the code, helps them to focus on writing only the code that they need.
4. The developer also notices that when they return to some code that they haven’t seen for a while, the tests serve to document how the code works.
5. A point of revelation occurs when the developer realises that writing tests in this way helps them to “discover” the API to their code. TDD has now become a design process.
6. Expertise in TDD begins to dawn at the point where the developer realizes that TDD is about defining behaviour rather than testing.
7. Behaviour is about the interactions between components of the system and so the use of mocking is fundamental to advanced TDD.

First you begin to write tests because you want to make sure your code works. But as you get into TDD, you realize that TDD really can be more about design than testing. If you can define acceptance criteria up front, you will be forced to think about what your code is going to need to do and design it accordingly.

BDD takes the next step. First your tests were just testing your code, then they were designing your code, and now they are describing what the code is doing. This is where the weird class and method names come in. Let me write out those tests again, translating it from C# into real world language.

Given an Employee, when validating an Employee, then the LastName is required and the BirthDate cannot be in the future. When an Employee makes a widget, then the LastWidgetDate should be set to today.

Here is where the light bulbs clicked on for me. My tests aren’t just testing my code, they are telling a story. Imagine if you were taking this code over from me and you wondered, “What is important about an Employee?” You could look at my tests and you would know exactly what is important about an Employee. You would immediately know what all of the acceptance criteria were for working with an Employee. So now you can go and change my code and have a good sense of what I was trying to make my code do!

I think by now you can see how TDD and BDD will go hand in hand. It should go something like this:

1) You get your requirements. In the requirements are a list of business rules or acceptance criteria.
2) You write your tests (or at least the classes and methods). Now you’ve translated those business rules and acceptance criteria into tests.
3) You write your code. You already have a suite of tests that you can run to know if you succeeded!

Of course, you may go back after the fact and write even more unit tests that focus on testing more granular parts of your implementation than just the overall business rules.

If you don’t like all the funky underscores that I put in the class and method names, then that’s fine. That’s just how we did it on our project (it’s all this guy’s fault). I like them because it really does help the names to read more like normal human sentences, which is much more valuable that I had originally thought.

TDD and BDD are a definite paradigm shift for a lot of people. But once you get used to it, you will never go back.

6 Comments »

  1. Jon, I couldn’t agree more with your points here. Just shifting the syntax of my tests to use the BDD wording is what pushed me over the top on gettng TDD through my head. Suddenly, what I was doing made so much sense, and it’s just snowballed from there. Thankfully.

    A word of caution, though is using the two terms totally interchangeably. Given the inability to get all the way into the code base of .Net, we’ll likely never achieve full on BDD in our environment. This is Bellware’s (via Steve Harman) BDD v. bdd argument. What we’re doing here is bdd…and when we shift to writing Ruby we’ll go for full on BDD. :)

    Tim — July 27, 2008 @ 11:06 am

  2. Jon-

    Great post. It answered a few questions I had about BDD. Keep em coming.

    Justin Kohnen — July 28, 2008 @ 2:39 pm

  3. [...] Why Behavior Driven Development is good [...]

    Jon Kruger’s Blog » Blog Archive » Unit Testing JavaScript - Introduction, JavaScript basics — November 25, 2008 @ 6:50 pm

  4. [...] is how you do behavior driven development. We took our acceptance criteria and wrote them out as code in the form of unit tests. These unit [...]

    Jon Kruger’s Blog » Software development is a series of translations — October 2, 2009 @ 6:57 am

  5. Hello, just wanted to say thanks for this post, I go back and refer to it every other day. :) It’s the one article that made BDD click for me. Thank you!

    Andreas — January 5, 2010 @ 4:13 am

  6. [...] is how you do behavior driven development. We took our acceptance criteria and wrote them out as code in the form of unit tests. These unit [...]

    TDD Boot Camp - Comprehensive Test-Driven Development Training in .NET – Software development is a series of translations — January 27, 2010 @ 9:46 pm

Leave a comment





SERVICES
SOFTWARE SOLUTIONS
I have over 10 years of software development experience on several different platforms (mostly Ruby and .NET). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
PROJECT LEADERSHIP
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
AGILE COACHING
I believe that Agile processes and tools should be applied with common sense. I've spent the last 6 years working on Agile projects as a consultant in many different environments, both in leadership roles and as a practitioner doing the work. I can help you find out how Agile can work best in your organization, not just apply a prescriptive process.
TEST DRIVEN DEVELOPMENT TRAINING
TDD Boot Camp is a hands-on, three day, comprehensive training course that will teach you all of the skills, tools, frameworks that you will need to use test-driven development to develop real world .NET applications. If you're not looking for something that intensive, check out the the half-day version.
Have any questions? Contact me for more information.
PRESENTATIONS
The Business of You: 10 Steps For Running Your Career Like a Business
From CONDG 2012, Stir Trek 2014
From Stir Trek 2013, DogFoodCon 2013
From Stir Trek 2012, QA or the Highway 2014
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010