Surviving a Zombie Apocalypse - Behavior Driven Development Part II

by Khalid Abuhakmeh 11. August 2008 08:37

So you've spent the time since part I either two ways: worrying more about BDD, TDD, and DDD or shaking at the idea that a zombie apocalypse might occur. Don't worry about either. This time around, I will finish up the introduction and show how to implement the scenarios of the specification so that your story passes. So last time we got as far as creating a story and writing the specification and a scenario, and getting each implementation to a state of pending. So let us tackle the scenario we setup last time.

ZombieApocalypsePart2.zip (253.34 kb) 

"Being attacked by a zombie"

 if you remember we had several requirments that needed to be fulfilled before passing the specification. Let us take on the first one, which is "Given I have a shotgun." Reading the specification in english we find we need two things to meet this requirment: A survivor, me, and a shotgun. So first thing I did was create the method we'll be using to pass the test. Note that the naming convention of your methods is very important to keeping the specification as close to the original reading as possible.

 

private static void IHaveAShotgun(Survivor me, Shotgun weapon)
{
Assert.IsNotNull(weapon);
Assert.IsNotNull(me);
//Grab the Shotgun
me.Shotgun = weapon;
// make sure I still have it
Assert.IsNotNull(me.Shotgun);
}

I still haven't created the Survivor or the Shotgun class yet at this point. I run the test and see that project won't compile. This is red-green development; it is to make sure that my test doesn't magically pass, there is some debate here about whether this should be done but I like doing it. So the next step is to create both the Survivor and Shotgun class. I will leave the creation of those classes out, but you can view the code in the download I include in this post. So now the assembly compiles after creating those classes, but if you run the tests through Gallio you'll notice that all the tests are still pending. Now we have to invoke the method in our scenario.

[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(() => IHaveAShotgun(me,weapon)) // implementation 
.And("the shotgun has ammunition")
.When("I shoot a zombie")
.Then("it should die");
horrorStory.Assert();
}
}

Now after we run the tests again through Gallio we should see that the Given part of the scenario passed, but all the other parts are still pending.

Now we'll implement the second method and call it in the same way we did the "Given" clause:

private static void TheShotgunHasAmmunition(Shotgun weapon)
{
// we still haven't loaded any ammo in the shotgun
Assert.IsTrue(weapon.Ammo == 0);
// Put some ammo in the weapon
weapon.Reload();
// Lock and loaded
Assert.IsTrue( weapon.Ammo > 0);
}

The result should look like the following:

and after implementing all, the code should look like this with a Gallio outcome of:

[Test]
public void SurvivingAZombieAttack()
{
Story horrorStory = new Story("Surviving a Zombie Attack");
Survivor me = new Survivor();
Shotgun weapon = new Shotgun();
Zombie attacker = new Zombie();
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(() => IHaveAShotgun(me,weapon)) 
.And(() => TheShotgunHasAmmunition(me.Shotgun))
.When(() => IShootAZombie(me,attacker))
.Then(() => ItShouldDie(attacker));
horrorStory.Assert();
}


There you have it, a fully implemented specification with scenario that passes all tests. I was writing unit tests for the classes I was creating while going about the process. I did not include them in the post but they can be seen by downloading the code. I hope this was enlightening and that its a push in the positive direction when it comes to BDD.

Advantages to BDD

 The biggest advantage to BDD is that you could get your business person or your customer to write out these specifications. This makes them accountable for the final product. Too often developers are left with all the burden of analyzing and creating the domain. This method allows for a tight interaction between developer and coustomer. What other advantages do you think there are to BDD, or do you think there are disadvantages?

Currently rated 4.0 by 1 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , , , ,

Code

Comments

Add comment


 

  Country flag

biuquote
  • Comment
  • Preview
Loading



Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

A Little Narcissism

I am a .NET developer mainly focused on Web development and enterprise applications. I strive to keep my skills at their best and always looking to absorb that much more knowledge. I am learning new things like Windows Workflow Foundation, LINQ, Ruby on Rails, WPF, ASP.NET MVC, and anything else thrown at me; I say bring it on!

RecentComments

Comment RSS