Geeks With Blogs
Blog Moved to Blog Moved to
Behavior Driven Development (BDD)  has been a big interest of mine lately and the way I tackle software design and development.  If you're looking for a good introduction as to what it is, follow the links plus a good introduction from Dan North and one from Tom Adams.

Just in case you've been living under a rock or off on some distant planet, you may ask, "Well, what is it?".  Well, in a way, it inherits from Test Driven Development and Domain Driven Design.  TDD had a failing by just performing tests against just business rules.  instead, BDD tends to get away from the technical stuff and ask in more wordy terms, "What should this application do?" or "What should this part do?".  By asking these questions and using this style, you can help share this across groups instead of the TDD style of just dealing with code.

Really, the intent is to ask about each part of the application, and then in turn the application entirely.  When you ask these questions in the beginning, it helps flush out any potential hazards when developing your applications when it comes to domain knowledge.

So, the next step is to prove the system design through behavior tests.  These tests should answer the questions the organization has about how the applications works.  The developer, namely you, needs to prioritize the questions and answer the most important ones first.  Once all the questions have been answered, sure enough, you have an application.

JP Boodhoo posted a getting started with BDD style Context/Specification base naming in which he describes using natural sentence style test naming.  The reason it became an issue is that many people were concerned about the aesthetics of the naming style.  He and Scott Bellware have been working together on BDD for quite some time.

Anyways, let's actually get to some coding shall we?  I'm tired of the sample of the bank account or general "Hello World" samples that tend to be out there.

When utilizing BDD, you should follow this pattern when writing your stories:

Title (one line describing the story)

As a [role]
I want [feature]
So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title
Given [context]
  And [some more context]…
When  [event]
Then  [outcome]
  And [another outcome]…

Scenario 2: etc

So, let's write one!

Register user on website

As a regular user
I want to register for the website
So that I can log into the system

Scenario 1: Register user with valid email address and password
Given that I have an email address and complex password
When I register
Then the user account is registered

Scenario 2: Register user with invalid email address format and valid password
Given that I have an invalid email address format and complex password
When I register
Then the user is rejected

Scenario 3: Register user with valid email address format and invalid password
Given that I have an email address and invalid password
When I register
Then the user is rejected

So, now that we got that, let's go ahead and write some code.  Keep in mind, the code comes last in a scenario like this.  JP stated in the previous post about naming the specs accordingly, so let's go ahead and do that.  Bring into the picture two favorite tools of mine.  MbUnit and NBehave.  What's great about this BDD design is that you still use your unit testing engine of choice.

public class UserRegistrationSpecs
     public class Register_User_With_Valid_Email_And_Password()
            Story transferStory = new Story("Register User on Site");

                .AsA("regular user")
                .IWant("to register on the site")
                .SoThat("I can log into the sysem");

                .WithScenario("Register User with Valid Email and Password")
                .Given("a user account", delegate() { userAccount = new UserAccount(); })
                .And("my email address is ",
                     delegate() { userAccount.EmailAddress = emailAddress; })
                .And("my password is ", "P@ssw0rd!",
                     delegate(string password) { userAccount.Password = password; } )
                .When("I register the account",
                      delegate() { userAccount.Save(); })
                .Then("the user should exist",
                      delegate() { Assert.IsTrue(UserAccount.Exists(emailAddress)); })

The tests go on encountering each scenario until you are done answering this question and all scenarios.  Remember this is only the first step.  There is plenty more to do with this scenario but I hope you see where I'm going with this.  Develop and Inspire!

kick it on Posted on Wednesday, December 5, 2007 1:41 AM Test Driven Development | Back to top

Comments on this post: Behavior Driven Development (BDD) and NBehave

# re: Behavior Driven Development (BDD) and NBehave
Requesting Gravatar...
BDD looks interesting.

I like the name NBehave... It reminds me of Austin Powers.

At the surface NBehave looks like a good way to do Integration testing. Do you feel that BDD should/could replace TDD and Unit Tests? Because I still see the value of testing small chunks of code in isolation of the rest of the system.
Left by Aaron Carlson on Dec 07, 2007 12:29 AM

# re: Behavior Driven Development (BDD) and NBehave
Requesting Gravatar...
No, I don't think BDD will completely replace Unit tests as they are pretty useful for testing things in isolation.

You need to come at this from a different angle with BDD. Instead, you are creating these scenarios in which your system will behave. For example, registering a user, with this and that, and when you do a certain action, this will occur. This is really powerful when you want to relate this to a business analyst instead of blindly looking at unit test code and maybe understanding it. It's trying to bring it up to a higher level so that more people can be involved and be more visible
Left by Matthew Podwysocki on Dec 07, 2007 11:05 AM

Your comment:
 (will show your gravatar)

Copyright © Matthew Podwysocki | Powered by: