There’s more to BDD than evolving TDD

Behaviour-driven development started life as an NLP exercise to stem the abuse of the word “test” in “test-driven development”. Since then it has grown into a respectable and proven agile methodology (with a small “m” of course).

Dave Astels, the award-winning author, was an early adopter of BDD and has been instrumental in raising its profile. He presented it at Canada on Rails and is taking it to JAOO and SD Best Practices. He has even presented it to Google. His Ruby BDD framework, rspec, has inspired a number of similar projects.

Now, Dave is a programmer. What’s more, he is a very thoughtful programmer, which means he invests a lot of energy in making programming productive and effective – and more importantly fun – for himself and other programmers. He doesn’t get very excited about capturing requirements or the dynamic between testers and analysts, so you won’t hear him talking about the wider context of BDD, but you will hear him saying that there is one!

BDD is fundamentally about identifying behaviour. At the analysis level, the behaviour of a story is its acceptance criteria, which BDD expresses in the form of automated scenarios. You need analysts working with testers to capture the stories and identify the acceptance criteria, and then you need programmers working with testers to automate the scenarios.

So the ironic twist is that all that talk about “testing” in TDD was taking the focus off the real testing action! My efforts to put the word “test” back in its box have in fact propelled the testers into the central role on a BDD team.

So the message here is twofold. Firstly, although a lot of the existing BDD message is in the TDD space, don’t lose sight of the bigger picture or you’ll miss out on all the good stuff. And secondly don’t underestimate the value of the testers on your team: they are your direct line to delivering high value software.

4 comments

  1. I would have said “don’t underestimate the value of skilled testing on your team”. Perhaps even “skilled test discovery”, which distinguishes it from test execution.

  2. Test-Driven Development has jumped the chasm to general acceptance. This is a good thing, but like Dave said in his Google video, there are still a high percentage of people who practices bad TDD. But there is also people who is practicing BDD while their doing TDD. So what is the difference? The one thing I have seen is that most people think that TDD is about Testing. When you explain that TDD is really at its hart a design process, they squawk at you and give you a look like you’ve lost your mind.

    I see TDD as performing the following roles:

    1. Design process
    2. Requirements Capturing
    3. Behavior Specification
    4. Regression Test Suite

    For this reason I think we need a Behavior-Driven Development framework.

    My daily development environment is .NET and C#, thus I would like to have something that suites my needs. Dave is working on rSpec for RoR and then there is JBehave for java. But I was unable to find anything for the .NET space. So I thought, I will roll my own.

    Here is what I have so far:

    using NBehave;

    namespace SampleBehaviour
    {
    [ Functionality ]
    public class CustomerLoadBehaviour
    {
    private Customer customer = null;

    [InitializeSpecification()]
    public void Setup()
    {
    customer = new Customer(123);
    }

    [ Specification() ]
    public void ShouldLoadCustomer()
    {
    Behaviour.Of( customer.Id ).Must.Not.Be.Null( “The Customer Id must not be null.” );
    Behaviour.Of( customer.Id ).Must.Equal( 123, “The customer id’s aren’t equal” );
    }

    [ Specification() ]
    public void LoadCustomerShouldFailed()
    {
    Behaviour.Of(customer.Id).Must.Not.Be.Null(“The Customer Id must not be null.”);
    Behaviour.Of( customer.Id ).Must.Not.Equal( 125, “The customer id’s aren’t equal” );
    }
    }
    }

    I’m busy working on a TestTip for VS2005, but have finished the NUnit integration.

  3. There is already an NBehave project underway. Graham Brooks is the project lead.

    The main differences between the xBehave (JBehave, NBehave) and xspec (rspec, sspec) families are:

    xspec uses the vocabulary of “specification” where xBehave talks about “behaviours”.
    xspec is exclusively looking at BDD-as-evolution-of-TDD, whereas xBehave is also about automating stories and scenarios.
    xspec extends the language to add DSL-type verification, so it is well-suited to dynamic languages (Ruby and Smalltalk are the current target platforms). xBehave uses <a href='http://joe.truemesh.com/blog//000511.html.Joe Walnes’s constraints-based approach>

    I’ll be releasing rbehave 0.1 just as soon as I can work out how to roll a Gem :)

    1. Thanks for pointing me in the NBehave project direction and the information surrounding the differences between rspec and xbehave.

      I think that my effort is more focused around BDD-as-evolution-of-TDD, a lot of my focus is around language. Trying to create a framework that is not obtrusive, but rather foster people to think in terms of the behavior /specification/functionality of the class they are trying to test-drive. For example my framework attributes is Functionality (TestFixture) and Specification (Test) to annotate the class and methods.

      I have found that developers new to TDD normally make all the usual mistakes and then loose faith in TDD. So take away the Test idiom and suddenly people think in terms of behavior and specification. Hopefully helping them to write better tests (specifications :-)…

      When are we going to see information surrounding the ideas behind jBehave and how to use it, etc…?

%d bloggers like this: