This little feature was added to the trunk today. Yes, no CreateSut() call. You can omit it for most of the simple scenarios. You can still override it, if you need/have to. It uses the AutoMocking capabilities of StructureMap internally.

I’m going to merge the different involved assemblies to a single assembly soon in order to make deployment a bit easier . . .

The main reason Dan North decided to use Should instead of all other  possibilities is, that Should implies that you can always question the behavior of your system. It isn’t written in stone. If you think the system doesn’t behave correctly any more, feel free to change or drop the particular spec.

I found this little comment of Dan North worth remembering . . .

Let’s start by looking back on my own efforts with testing and BDD. For about 2 years I wrote (what I consider to be) classical unit tests. Those tests followed strictly a “<MethodName>_<Scenario>_<Behavior>” naming convention originally proposed by Roy Osherove. Here’s short example of what I wrote that time.

[Fact]
public void RegisterSubscriber_NewSubscriber_SubscriberIsRegistered()
{
    var subscriber = new FakeSubscriber();

    subscriptionManager.RegisterSubscriber(subsriber);

    var wasRegistered = subscriptionManger
                                     .AllSubscriptionsFor()
                                     .Contains(subscriber);

    Assert.TruewasRegistered);
}

When changing my tests to a more BDD oriented style last august (if you’re interested why please read here), my style of writing tests changed to something that looked like this.

[Concern(typeof(SubscriptionManager))]
public class When_registering_a_subscriber_at_the_subscription_manager : InstanceContextSpecification
{
    ISubscriber subscriber;

    protected override void EstablishContext()
    {
        subscriber = new FakeSubscriber();
    }

    protected override SubscriptionManager CreateSut()
    {
        return new SubscriptionManager();
    }     

    protected override void Because()
    {
        Sut.RegisterSubscriber(subscriber);
    }

    [Observation]
    public void should_be_contained_in_the_list_of_subscriptions_for_the_subscribed_message()
    {
        subscriptionManger
           .AllSubscriptionsFor()
           .ShouldContain(subscriber);
    }
}

For me at that particular point BDD meant not much more than a bunch of proven practices in test design and a revised naming convention. So what might be wrong with the way the spec is written here (event in that context)?

1. It isn’t fully refactoring safe (to be fair, the classic unit test shown above wasn’t either). Try to rename the term SubscriptionManager (or RegisterSubscriber in the first example). No refactoring tool will help you renaming your existing specs. As a consequence I would strongly suggest not to encode type or member names into a specification.
2. It doesn describe behavior. It describes implementation. A spec should describe what a system under test is supposed to do, not how it achives it.  Do you see the word “list” here?

You could revise the spec like this.

[Concern(typeof(SubscriptionManager))]
public class When_registering_a_new_subscriber : InstanceContextSpecification
{
    ISubscriber subscriber;

    protected override void EstablishContext()
    {
        subscriber = new FakeSubscriber();
    }

    protected override SubscriptionManager CreateSut()
    {
        return new SubscriptionManager();
    }     

    protected override void Because()
    {
        Sut.RegisterSubscriber(subscriber);
    }

    [Observation]
    public void should_enable_the_subscriber_to_recieve_messages_he_is_interested_in()
    {
        subscriptionManger
           .AllSubscriptionsFor()
           .ShouldContain(subscriber);
    }
}

Having said this, IS THAT THE REASON why I consider wording be to so important to BDD?

No, not really. Nearly the same applies to classic unit testing, too.  We should take a closer look at BDD in order to reach the answer.

Was the example shown above even BDD?

IMHO Second no. The example isn’t BDD. It only shows a way how a part of BDD can be implemented, with a framework; be it xunit.bddextensions, SpecUnit, MSpec or any other tool out there.

Ahm, ok what is BDD then?

As I understand it so far, BDD was originally created to codify acceptance criterias of stakeholders into executable code in a way which preseverves most/all of the vocabulary the stakeholder uses. By that a shared language can be established between stakeholders.  (Greg Young wrote a nice post about the subtle difference between BDDs shared language and DDDs ubiquitous language, so I won’t repeat that here).  This shared language is ment to enhance the way different parties/stakeholders interact with each other, a way to enhance communication. And what is the primary utility used in the interactions between stakeholders in BDD? ==> The executable specifications. <==

Coming back to why wording is so important to BDD

What is especially interesting in BDD is, that as there’re different stakeholders, there’re also different kind of audiences, with possibly different kind of vocabulary.  So because BDD specs are targeted to be an acceptance criteria, they need to be written in the vocabulary of the people who will review them. This is a huge influence  besides all the more technical reasons I touched earlier which of course are relevant, too.

Does this make sense to you?

What bothers me lately is that this style mixes context and behavior under test into one fixture class name, which can be extremely long because of that. An example to clarify what I mean:

 public class When_adding_a_contact_to_a_user_with_no_existing_contacts { }
 

“Adding a contact” is the observed behavior in the context of “no existing contacts”. I believe
this should be more obvious, which made me thinking of how a syntax for this could look like.

Having said that, here is what I came up with. It’s heavily inspired by MSpec and RBehave.

[SpecificationFor(typeof(PatientService))]
public class A_patient_with_a_missing_first_name_is_not_allowed_to_be_persisted
{
      Given a_patient_with_a_missing_first_name = () =>
      {
      };

      When trying_to_save_the_patient = () =>
      {
      };

      It should_not_persist_the_supplied_patient = () =>
      {
      };

      It should_return_a_report_indicating_that_the_patients_first_name_is_required = () =>
      {
      };
}

A generated report for this code might look like this:

Specifications for “PatientService”

• A patient with a missing first name is not allowed to be persisted
  • Given a patient transfer object with a missing first name
  • when trying to save the patient
    • it should not persist the supplied patient
    • it should return a report indicating that the patients first name is required
      

I’m still not 100% happy with this, because there is some sort of duplication between the fixture name and the “givens” (at least in the shown example), but with this approach you

1. are able to separate context and behavior in a clean way,
2. can describe the context very fine grained (by having multiple “givens”)
3. and besides that it looks cool

I would like to hear opinions on that. Is this something worth implementing / adding to xUnit.BDDExtensions?
Or am I off the track with this?

xUnit.BDDExtensions is a little framework build on top of xUnit which enables a BDD style of testing with xUnit.

Besides an emphasis on a “test case class per fixture” organization scheme for tests, AAA (Arrange, Act and Assert) style of writing tests and left to right assertions, this framework also provides Rhino.Mocks integration out of the box. By hiding the mechanics of Rhino.Mocks (record and replay model, mocks vs. stubs) behind the scenes, xUnit.BDDExtensions also helps on writing cleaner, easier to understand and less brittle tests

xUnit.BDDExtensions is based on JP Boodhoos BDD extensions for MBUnit used in his “Nothing but .NET” bootcamps.

Enough of the talking, let’s look at some code

This is actual code of the xUnit.BDDExtensions trunk. The SpecificationTestCommand class serves as a kind of adapter inside xUnit. It enables the test class to have methods that are run before and after the actual test method is executed.*

    public class SpecificationTestCommand : BeforeAfterCommand
    {
        public SpecificationTestCommand(
            ITestCommand innerCommand,
            MethodInfo testMethod)
            : base(innerCommand, testMethod)
        {
        }

        public override MethodResult Execute(object testClass)
        {
            var specification = testClass as ITestSpecification;

            try
            {

                if (specification == null)
                {
                    throw new InvalidOperationException(
                          "Instance does not implement ITestSpecification");
                }

                specification.InitializeSpecification();
                return base.Execute(testClass);
            }
            finally
            {
                if (specification != null)
                {
                    specification.CleanupSpecification();
                }
            }
        }
    }

Notice several things:

1. It expects the instance to implement ITestSpecification.
2. It calls the InitializeSpecification() method on it
3. Passes the execution to the inner command (in base.Execute(obj))
4. and finally cleans up the specification by calling CleanupSpecification() on it.

So how can a completely isolated happy path test for this look like?

 [Concern(typeof(SpecificationTestCommand))]
 public class when_a_specification_test_command_is_executed_on_a_ITestSpecification_implementer :
        concern_for_specification_test_command
    {
        private MethodResult expectedTestResult;
        private ITestCommand innerCommand;
        private MethodInfo methodInfo;
        private MethodResult testResult;
        private ITestSpecification testSpecification;

        protected override void EstablishContext()
        {
            innerCommand = Dependency();
            testSpecification = Dependency();
            methodInfo = GetTestMethodHandle();
            expectedTestResult = CreateMethodResult(methodInfo);

            innerCommand.WhenToldTo(x => x.Execute(testSpecification))
                     .Return(expectedTestResult);
        }

        protected override SpecificationTestCommand CreateSut()
        {
            return new SpecificationTestCommand(innerCommand, methodInfo);
        }

        protected override void Because()
        {
            testResult = Sut.Execute(testSpecification);
        }

        [Observation]
        public void should_ask_the_test_specification_to_initialize()
        {
            testSpecification.WasToldTo(x => x.InitializeSpecification());
        }

        [Observation]
        public void should_pass_the_test_specification_to_the_inner_test_command()
        {
            innerCommand.WasToldTo(x => x.Execute(testSpecification));
        }

        [Observation]
        public void should_return_the_test_result_from_the_inner_test_command()
        {
            testResult.ShouldBeEqualTo(expectedTestResult);
        }

        [Observation]
        public void should_ask_the_test_specification_to_cleanup()
        {
            testSpecification.WasToldTo(x => x.CleanupSpecification());
        }
    }

Notice several things:

1. In the EstablishContext() method the whole context for the test is created. This includes creating most of the dependencies with Rhino.Mocks through Dependeny() and the necessary configuration of their behavior. This is done in order to quickly get from an interaction based style of testing to a state based style of testing. In AAA terms this method implements the Arrange part.
2. The CreateSut() method is executed after EstablishContext() and creates the actual system under test.
3. The Because() method implements the actual behavior under test. In AAA terms this is the Act part. In the current example this meant executing the test command with an instance implementing the expected interface.
4. Each method marked with the ObservationAttribute contains a single observation which should be fulfilled when the test has been executed. In AAA terms every Observation is an Assert.

That’s basically it. Pretty straight forward imho. If I managed to make you at least a bit curious about this style of testing, you can grab the source with any Subversion client from:

http://xunitbddextensions.googlecode.com/svn/trunk/

Enjoy coding

*
I know xUnit dropped this behavior in favor of the dispose pattern, but having explicit, non technically named methods for that still seems more natural in the context of BDD to me.

So here it is. Any feedback is appreciated . . .

A short description of my problem

I’m using a test-case-class-per-fixture organization and the template method pattern for writing tests in the AAA scheme. Besides that I use a specialized FactAttribute in order to invoke my AAA – hook methods in the correct order. All of this is residing in a separate assembly.

When I use the build-in FactAttribute to mark my tests alll tests are discovered by the Resharper’s TestExplorer, but when I’m using my own marker attributes nothing is discovered.

What seems to be the problem

It took me some time to find out what was actually going on. I’ve never debugged a Resharper-Plugin before. This helped a lot. It was an interesting experience, though. Didn’t knew that there is so much going on behind the scenes. This is what I found out:

• The XUnitTestProvider class is responsible for discovering tests.
• It skips all assemblies which don’t reference xunit directly.

Hm, I had a reference to xunit in my test library project settings. However I was not referencing xUnit stuff from my code directly (Own FactAttribute and xunitext35 extension methods for assertions). That’s when it hit me:

My problem was probably caused by a compiler optimization. It seems that all unused assembly references are removed when building the test assembly. A look into reflector supported my thesis. So my test assembly has no direct reference to the xunit.dll, only an indirect one through the BDD framework.

Patching this is quite easy

This is the original method:

static bool IsTestAssembly(IMetadataAssembly assembly)
{
        foreach (AssemblyReference reference in assembly.ReferencedAssembliesNames)
               if (reference.AssemblyName.Name.ToLowerInvariant() == "xunit")
                     return true;

        return false;
}

When changing this a bit to this, everything runs as expected.

static bool IsTestAssembly(IMetadataAssembly assembly)
{
        foreach (AssemblyReference reference in assembly.ReferencedAssembliesNames)
        {
              string assemblyName = reference.AssemblyName.Name.ToLowerInvariant();

              if (assemblyName.StartsWith("xunit"))
                   return true;
       }

       return false;
}

All tests are discovered and I’m quite happy that I can use BDD, XUnit and Resharper in combination

One thing to be aware of: In order to get the tests not only discovered but also executed in Resharper you’ll have make sure that your test project and the Resharper addin are both using the same, exact version of xUnit. I stumbled over this after I recompiled and installed my patch on my machine. Resharper is not able to execute the tests in case of a version mismatch.

Some of the things I really like about it:

• It has a set of .NET 3.0 Extension methods, which can be used instead of classic assertions (f.e.: “Foo”.ShouldNotBeNull() )
• It runs every every test on a separated instance.
• It uses the constructor of the test class and the Dispose-pattern for fixture initialization and release of resources after a test.
• It’s relatively easy to extend XUnit.

Because of curiosity and my current affection with BDD I decided to port the BDDExtension stuff from  JP Boodhoo to XUnit. So here we go:

Marking specifications with concerns

All specifications for a particular type are marked with the ConcernAttribute.  This is only a marker attribute by which a tool like bddunit is able to correlate specifications and their related type.

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
public class ConcernAttribute : TraitAttribute
{
        private readonly Type _Type;

        public ConcernAttribute(Type type) : base("Concern", type.FullName)
        {
                _Type = type;
        }

        public Type Type
        {
                get { return _Type; }
        }
}

The ConcernAttibute extends the TraitAttribute which is described in the documentation as “an Attribute used to decorate a test method with arbitrary name/value pairs (“traits”).” I changed the AttributeTarget from method to class in order to suit my needs.

Changing the way the test is executed

JP’s original code relied on the SetUp and Teaddown handlers of NUnit / MBUnit which are execute before and after each test method in the same class. Since XUnit doesn’t have that feature any more we’ll have to extend it a bit.

The main extension point for how a test is executed is the FactAttibute used to mark a method as a test. You can extend it and return a different ITestCommand which is then used to execute the test.

public class ObservationAttribute : FactAttribute
{
        protected override IEnumerable EnumerateTestCommands(MethodInfo method)
        {
                var testCommand = base.EnumerateTestCommands(method).First();
                yield return new SpecificationTestCommand(testCommand, method);
        }
}

Do you wonder why the method returns an IEnumerable<ITestCommand>? This is done in order to support something like row tests in MBUnit. The XUnit framework basically enables you to run a test several times. For me this isn’t interesting so I just grabbed the first ITestCommand from it and wrapped it with my own implementation, which looks like this:

public class SpecificationTestCommand : BeforeAfterCommand
{
        public SpecificationTestCommand(
                ITestCommand innerCommand,
                MethodInfo testMethod)
                : base(innerCommand, testMethod)
        {
        }

        public override MethodResult Execute(object testClass)
        {
                var specification = testClass as IContextSpecification;

                if (specification == null)
                {
                       throw new InvalidOperationException(
                          "Instance does not implement IContextSpecification");
                }

                try
                {
                        specification.EstablishContext();
                        specification.Because();
                        return base.Execute(testClass);
                }
                catch(AssertException)
                {
                        throw;
                }
                catch (Exception exception)
                {
                        ExceptionUtility.RethrowWithNoStackTraceLoss(exception.InnerException);
                }

                return null;
        }
}

The code requires the test class to implement the IContextSpecification interface in order to invoke the EstablishContext() and Because() methods for doing AAA based tests. (Do you miss AfterEachSpec? One moment please ) For every interface there is a base class which is in my case the ContextSpecification class.

public abstract class ContextSpecification : IContextSpecification, IDisposable
{
      protected abstract void Because();

      protected abstract void EstablishContext();

      protected virtual void AfterEachSpec()
      {
      }

      #region IContextSpecification Members

      void IContextSpecification.Because()
      {
            Because();
      }

      void IContextSpecification.EstablishContext()
      {
            EstablishContext();
      }

      #endregion

      #region IDisposable Members

      public void Dispose()
      {
            AfterEachSpec();
      }

      #endregion
}

Notice some things. AfterEachSpec() is called from Dispose(), That’s why I didn’t need to include it into the IContextSpecification interface. That interface is implemented explicitly in order to allow the hooks to have different modifiers (protected).

A first test

There’s always an interesting moment when you first run your little experiment. Here we go:

[Concern(typeof(Factory))]
public class When_creating_product_with_a_valid_name : ContextSpecification
{
      private Factory _Factory;
      private Product _CreatedProduct;

      protected override void EstablishContext()
      {
            _Factory = new Factory();
      }

      protected override void Because()
      {
            _CreatedProduct = _Factory.Create("Foo");
      }

      [Observation]
      public void The_product_should_contain_the_correct_name()
      {
            _CreatedProduct.Name.ShouldEqual("Foo");
      }

      [Observation]
      public void The_product_should_contain_the_correct_vendor_name()
      {
            _CreatedProduct.VendorName.ShouldEqual("FooVendor");
      }
}

And the result from TestDriven.NET is:

—— Test started: Assembly: Xunit.BddExtensions.Samples.dll ——
2 passed, 0 failed, 0 skipped, took 0,92 seconds.

Conclusions

It’s in fact very easy to extend XUnit. I like the tool even more after doing this little research. The shown code runs smoothly with TestDriven.NET. However the Resharper – TestRunner seems to have problems with it (TestExplorer stays blank).

I’ll play with that approach in the next few weeks and will blog about my experience with both XUnit and BDD. So if you’re interested in more stay tuned . . .

P.s.: If you’re interested in the code, just drop me a line . . .

BDD is described by its creator Dan North as an enhancement to classic TDD with an emphasis on behavior specifications. It tries to provide business value by using classes and methods written as human readable sentences which can be reflected in order to generate a behavior specification document for the classes under test. The document can fulfill multiple purposes. It could be used as documentation for the tested system and even more important as an enabler for the ubiquitous language of the project (in terms of Evans DDD).

Before looking at something more concrete about BDD, first a brief history of my personal experience with testing throughout the last 3 years. I think this helps me to clarify, why I liked BDD from the moment I started reading about it.

My first unit tests looked very much like a lot of tests I’ve seen from a lot of people starting with unit tests since. (The examples are using the NUnit syntax but you can project this to any unit testing framework you want.)

Every fresh start is hard.

[TestFixture]
public class FactoryTest
{
    private Factory _Factory;

    [SetUp]
    public void SetUp()
    {
          _Factory = new Factory();
    }

    [Test]
    public void Test1()
    {
           SomeProduct product = _Factory.Create("FooProduct");

           Assert.IsNotNull(product);
           Assert.AreEqual(product.Name, "FooProduct");
           Assert.AreEqual(product.Vendor, "Foo");
    }

    [Test]
    [ExpectedException(typeof(ArgumentNullException))]
    public void Test2()
    {
           _Factory.Create(null);
    }
}

For every class I wanted to test I wrote a corresponding test class, which had the suffix “Test” and contained all tests for that class under test. I discovered later that this is a testing strategy known as TEST-CASE-CLASS-PER-CLASS while reading “XUnit Test Patterns” by Gerard Meszaros. At that time it felt pretty confident with what I did. I mean, I wrote tested code, which was to a particular degree bug free. Yeah right, but let’s have a look at the downside of what I was doing:

• When such a test failed I didn’t have a clue what the test was actually verifying. I had to debug the testcode.
• When a test like “Test1″ failed I didn’t know what assertion was broken. I had to debug the testcode.
• It didn’t scale well. I became quite messy and unclear as the number of tests increased.
• I always hat a hard time coming back to the test after having spend days in a different topic.

Incorporating a standard naming scheme for tests

As one result of the observed problems I incorporated a standard naming scheme (inspired by a post of Roy Osherove) to my tests which followed the following scheme:

MethodName_Scenario_Behavior

Applied to the sample code it would look like this:

[TestFixture]
public class FactoryTest
{
    private Factory _Factory;

    [SetUp]
    public void SetUp()
    {
          _Factory = new Factory();
    }

    [Test]
    public void Create_ValidCreationData_CreatesAValidProduct()
    {
           SomeProduct product = _Factory.Create("FooProduct");

           Assert.IsNotNull(product);
           Assert.AreEqual(product.Name, "FooProduct");
           Assert.AreEqual(product.Vendor, "Foo");
    }

    [Test]
    [ExpectedException(typeof(ArgumentNullException))]
    public void Create_NullForArgument_ThrowsArgumentNullException()
    {
           _Factory.Create(null);
    }
}

The naming scheme helped me a lot for maintaining my tests. When a test failed I knew instantly a) which class was tested, b) what the test scenario was and c) what the expected behavior was, that was broken. However, the problem with the multiple assertions still existed. You can fix this issue by providing error messages with every assertion. I must admit that I never really liked that approach. I would rather go down the SINGLE-ASSERTION-PER-TEST-METHOD way. This way you have the behavior of the class under test completely discoverable by a unit test framework which is something I appreciate. (Maybe I’m alone with this. Several members of my team disagree with this.)

Single Assertion per Test

After refactoring the test it would look like this:

[TestFixture]
public class FactoryTest
{
    private Factory _Factory;

    [SetUp]
    public void SetUp()
    {
          _Factory = new Factory();
    }

    [Test]
    public void Create_ValidCreationData_CreatedProductHasName()
    {
           SomeProduct product = _Factory.Create("FooProduct");
           Assert.AreEqual(product.Name, "FooProduct");
    }

    [Test]
    public void Create_ValidCreationData_CreatesProductHasNameOfVendor()
    {
           SomeProduct product = _Factory.Create("FooProduct");
           Assert.AreEqual(product.Vendor, "Foo");
    }

    [Test]
    [ExpectedException(typeof(ArgumentNullException))]
    public void Create_NullForArgument_ThrowsArgumentNullException()
    {
           _Factory.Create(null);
    }
}

One downside of this approach is the sudden code duplication you now have in the code. It isn’t that big in the example but it can be in reality. You should treat test code as you’re treating production code. Don’t repeat yourself! I usually dealt with that situation by switching the test strategy.

Switching to TEST-CLASS-PER-FIXTURE

TEST-CLASS-PER-FIXTURE is again a test strategy described by Gerald Meszaros in this book “XUnit Test Patterns”. The basic idea is that you split your test classes into several test classes based on the common initialization / execution logic the methods share. Applied to the sample code this would result in this:

[TestFixture]
public class FactoryTest_ArgumentTests
{
    private Factory _Factory;

    [SetUp]
    public void SetUp()
    {
          _Factory = new Factory();
    }

    [Test]
    [ExpectedException(typeof(ArgumentNullException))]
    public void Create_NullForArgument_ThrowsArgumentNullException()
    {
           _Factory.Create(null);
    }
}

[TestFixture]
public class FactoryTest_CreatingAValidProduct
{
    private Factory _Factory;
    private SomeProduct _Product;

    [SetUp]
    public void SetUp()
    {
          _Factory = new Factory();
          _Product = _Factory.Create("FooProduct");
    }

    [Test]
    public void Create_ValidCreationData_CreatedProductHasName()
    {
           Assert.AreEqual(_Product.Name, "FooProduct");
    }

    [Test]
    public void Create_ValidCreationData_CreatesProductHasNameOfVendor()
    {
           Assert.AreEqual(_Product.Vendor, "Foo");
    }
}

I’ve worked with that approach for 2 years now. It suited my needs very well. However the tests are often not as expressive as I like them to be in terms of the naming. I’ll guess there’s a better naming scheme when using something like the TEST-CASE-CLASS-PER-FIXTURE testing strategy and that’s where the circle closes for me.

Coming back to BDD

While working through the preparation material for JP Boodhoos Nothing but .NET bootcamp I made first contact with his style of applying BDD. I must admit that I’m pretty amazed, because I’ve seen a lot of things of value for me. Sometimes sourcecode says more than a thousand words, so this is what the sample would look like if his BDD conventions have been applied to it:

[Concern(typeof (Factory))]
public class When_creating_a_valid_product : ContextSpecification
{
     private Factory _Factory;
     private Product _CreatedProduct;

     protected override void establish_context()
     {
            _Factory = new Factory();
     }

     protected override void because()
     {
           _CreatedProduct = _Factory.Create("Foo");
     }

     [Observation]
     public void the_product_should_contain_the_correct_product_name()
     {
          _CreatedProduct.Name.should_be_equal_to("FooProduct");
     }

     [Observation]
     public void the_product_should_contain_the_correct_vendor_name()
     {
          _CreatedProduct.Vendor.should_be_equal_to("Foo");
     }
}

[Concern(typeof (Factory))]
public class When_passing_null_for_product_name : ContextSpecification
{
     private Factory _Factory;
     private Action _Call;

     protected override void establish_context()
     {
            _Factory = new Factory();
     }

     protected override void because()
     {
           _Call = The.Action(() => _Factory.Create(null))
     }

     [Observation]
     public void should_throw_an_ArgumentNullException()
     {
           _Call.should_throw_an<ArgumentNullException>();
     }
}

Here is the base class that provides the hooks for the unit test framework (in this case MbUnit).

using MbUnit.Framework;
using Context = MbUnit.Framework.TestFixtureAttribute;

namespace NothinButDotNetPrep.SpecHelpers
{
    [Context]
    public abstract class ContextSpecification
    {
        [SetUp]
        public void setup()
        {
            establish_context();
            because();
        }

        [TearDown]
        public void teardown()
        {
            after_each_specification();
        }

        protected abstract void because();
        protected abstract void establish_context();
        protected virtual void after_each_specification()
        {
        }
    }
}

I like his way to implement the AAA (arrange, act and assert) pattern with the template method pattern and C# 3.0 extension method for the actual assertions very much. It feels like a natural progression to what I’ve been doing previously with a lot better readability. Another interesting thing is that he uses a tool called bddunit to generate a behavior documentation from the tests. A generated documentation would look like this:

Behavior of Factory

• When creating a valid product
  • the product should contain the correct vendor name.
  • the product should contain the correct product name.
• When passing null for product name
  • should throw an ArgumentNullException

I’ll definitely have to dig more into this. If you’re interested in learning more about BDD here are some links I’ve read this morning.

• Dan North: Introducing BDD.
• AgileJoe: Attempting to demyistify BDD.
• JP: Bodhoo: Getting started with BDD style Context / Specification base naming.
• Jimmy Bogard: Converting tests into specs is a bad idea.
• David Laribee: Approaching BDD.