So the world has descended into a zombie apocalypse and the streets are rampant with the flesh eating undead, what do you do? Grab a shotgun of course and start shooting! I've seen enough movies to know that zombies have a hard time functioning without their heads. Use your ammo wisely and you will survive, act reckless and you will join the ranks of the undead.

Are you wondering what a zombie apocalypse has to do with behavior driven development (BDD)? Well what I just described is a story, and stories are a very critical part of BDD. Stories describe the problem that you encounter in your domain. This current domain is a zombie apocalypse in which you, the survivor, need to find a way to keep alive. BDD is very closely tied to Test Driven Development (TDD) and Domain Driven Design (DDD). I know I just threw a bunch of acronyms at you, but it will all make sense soon. Before we start, you are going to need a couple frameworks and .NET tools: Gallio - Automation Platform for .NET, NUnit, and StoryQ.

ZombieApocalypse.zip (228.34 kb) (VS2008 required, upgrade already!)

So the first step is to describe our story, in plain English so that the normies understand.

As a survivor of the zombie apocalypse I want to survive the zombie hordes so that I can find a cure to the zombie disease.

so now I have my story, and I have also defined my intention or specification. That's pretty simple, but what's the code representation look like. Well it looks something like this:

Story horrorStory = new Story("Surviving a Zombie Attack");
horrorStory.AsA("As a survivor of the zombie apocalypse")
.IWant("to survive the zombie hordes")
.SoThat("I can find a cure to the zombie disease")

Great! now that looks like code, but don't try to compile it just yet, that is only the story. We are going to need scenarios for surviving a zombie attack. Scenarios present a specific situation about the overall problem in attempts to solve the overall problem. These scenarios are accumulated to help understand and eventually solve the larger problem. Our particular scenario is going to include a shotgun. Lets say it again in English so that we understand our scenario.

Being attacked by a zombie : Given that I have a shotgun that has ammunition when I shoot a zombie then it should die!

Now the code :

[TestFixture]
public class ZombieSurvivalSpecification
{
[Test]
public void SurvivingAZombieAttack()
{
Story horrorStory = new Story("Surviving a Zombie Attack");
horrorStory.AsA("As a survivor of the zombie apocalypse")
.IWant("to survive the zombie hordes")
.SoThat("I can find a cure to the zombie disease")
.WithScenario("Being attacked by a zombie")
.Given("I have a shotgun")
.And("the shotgun has ammunition")
.When("I shoot a zombie")
.Then("it should die");
horrorStory.Assert();
}
}

Amazing, we just wrote our first BDD specification and hopefully well enough to save our necks. Now let us run this specification using Gallio. First build the project with the tests and then open Gallio Icarus test runner. You will see an assemblies menu at the top of the test runner, add the test assembly to the runner and then click the start button. The outcome should look like the following:

You'll notice that test did not pass, instead it was set to a state of warning. This is because we haven't met the needs of the specification yet. We just setup the specification, we will need to implement each line that has a *pending next to it. You'll start noticing that our specification and scenarios are starting to develop a domain: Zombie, Shotgun, and Ammo. In the next part of this BDD series, we will actualize the zombie, shotgun, and ammo using traditional TDD red green development, and also implement the code to meet the needs of the specification.

Hold on for the next part in the series and you will survive the zombie apocalypse and learn a little more about BDD, TDD, and maybe some DDD (say that three times fast).