.NET Musings

I was fortunate to sit it on an excellent talk given by Lee Brandt on an introduction to BDD using Machine Specifications (MSpec).  As a long time Test Driven Design guy, it intrigued me, since the specification style of Behavior Driven Development seems to address several issues that I have teaching TDD to customers and conference attendees.

For a background on BDD, please see Dan North’s blog (who coined the term and pioneered a lot of these concepts), and on the Context Specification style of BDD that Scott Bellware discusses in the Code article.  I am by no means an expert on BDD (or it’s history), so I won’t attempt to document how we have come to where we are in this practice, and I apologize for any omissions of key names in this field.  I also am stating that I am new to BDD, so please feel free to give constructive criticisms in the comments, or ping me directly through my contact page.

For me, a passionate TDD practitioner, the biggest hurdle for me in teaching TDD is getting past the word “Test”.  It’s almost as if it should be named Driving Design through Testing, but DDT has such a bad rap.  the other problem (significant, but not nearly the level of friction of “test”) is sharing the tests with QA or Product Owners.  I have developed workarounds over time, including using SandCastle to create documentation, but those still require more time than I want to give.

The biggest change in switching to BDD is in the language.  In TDD, we name classes and methods in a meaningful way to expose what we are testing.  Unfortunately, we tend to name them in a way that is really only meaningful to developers.  It is very easy to fall into this trap, and then it gets very difficult to communicate with the non-developers (such as Product Owners, customers, etc).

Here is a (very) contrived example to illustrate the point (and my newbie understanding of BDD).  If we have a User Story and acceptance criteria that reads:

As a User,
I want to log in to the system
So that I can view my cart.

Acceptance Tests:
User must have a valid user name and password.
User’s Shopping Cart is populated

How I would typically code this (I know there are several other ways to do this that are more BDD-like) is create a test class for each line of business class, and then create tests to flush out the User Story and the acceptance criteria.  The shell would look something like this:

[TestFixture]

public class LoginTests

{

    [Test]

    public void Should_Login_With_Valid_Username_And_Password()

    {

       //test body eliminated for brevity

    }

    [Test]

    public void Should_Retrieve_Shopping_Cart_When_User_Logs_in_With_Valid_Username_And_Password()

    {

       //test body eliminated for brevity

    }

    [Test]

    public void Should_Fail_Login_With_Invalid_Username_And_Password()

    {

       //test body eliminated for brevity

    }

}

This is very readable for a developer, but not so much for a non-developer (sometimes we call them “humans”).

The theory (as I understand it) behind Context Specification is enabling the developers and non-developers to speak the same language.  This point (of finding a ubiquitous language) is a key concept in Eric Evans’ concepts with Domain Driven Design.  If we take the above user story and turn that into a Context Spec it would look something like this:

Concern: Login

Context: When Logging Into the application with a valid user name and password

Observation: Should authenticate the user into the application
Observation: Should reload the user’s shopping cart should be from their last session

Context: When Logging Into the application with an invalid user name or password

Observation: Should not authenticate the user into the application

As a litmus test, I ran these by one of my customers to get their feed back.  When I showed them the first example, they looked at me like I was an alien.  When I showed them the second example, they immediately “got it”.  Ok, so I’m sold on the style.  Now, how do we code this?

In my next post I will document my journey into flushing out these specifications with MSpec.

Happy Coding!