On the Scot ALT.NET meeting held on 4th November Robert Lewis gave a talk on BDD explaining the basics, motivations and demonstrating the .NET tools available to support this methodology. I found the talk to be really interesting, mostly because Robert was focusing on the practical side of BDD – that is how .NET developers can use this methodology and at what projects might this be beneficial.

What is BDD?

If you haven’t heard of BDD yet, Dan North’s Introducing BDD or the BDD summary on Wikipedia is a good place to start. In a nutshell BDD is making another step of abstraction from TDD with the help of Domain Driven Design.

Instead of specifying atomic level unit tests, it tries to describe the desired behaviour of the software with natural language sentences. These sentences can then be written by the non-technical end users allowing them to get involved in the testing process. The sentences – often referred to as user scenarios – are then implemented by the developer as a series of unit tests.

BDD Frameworks for .NET

There are currently two BDD frameworks .NET developers can use to implement this methodology: NBehave and the IronRuby compiled version of Cucumber.

NBehave is a .NET version inspired by Dan North’s JBehave. It basically allows user defined stories in a text file to be mapped to a series of test functions. For example the sentence “Given I have logged in to the system, when I start a new transaction, then I will have to enter my password” can be mapped to the test functions:

[ActionMethod]
public void Given_I_have_logged_in_to_the_system() 
 
[ActionMethod]
public void When_I_start_a_new_transaction() 
 
[ActionMethod]
public void I_will_have_to_enter_my_password()

The mapping can be be done in a more readable way, by having attributes containing the mapping strings e.g.

[ActionStep("I have logged in to the system")]
public void Login()

The framework goes through the user defined sentences, does the mapping and outputs whether the user stories have failed or succeeded. This way BDD can be implemented via the Red-Green-Refactor cycle which is familiar to ones using TDD.

NBehave has support for using regex expressions when mapping user stories and test functions which gives it a larger flexibility compared to having to define individual test methods for every test. It’s also worth noting that it supports most .NET unit testing libraries suggesting integration into existing projects using these libraries is smooth.

The main drawbacks of the framework are that it’s not really documented and there’s no support for defining the same user stories with different parameters – you have to write them down again each.

Cucumber is a Ruby based tool which seems to be better documented and more feature-rich than NBehave (e.g. having the support for defining parameters for a given user story in a table-like format). Thanks to the IronRuby implementation it can be compiled to run on .NET.

However the performance of the application is really slow at the moment – probably due to the limitations of IronRuby. Both Robert Lewis and the audience at the ALT.NET event agreed that IronRuby has to improve before Cucumber could be used in production.

Summing it up there is some existing .NET BDD support but at the moment it seems quite basic. If you want to integrate BDD in your project the best bet at the moment would be NBehave – or if you have specific needs then implementing a tool for yourself.

When and how does BDD help me?

Just as any other agile methodology, BDD is not a universal solution and won’t always help your software process. As it’s basically another abstraction over TDD it is a more expensive process so it’s unlikely to be efficient in small projects.

BDD can be a realistic option in complex projects where TDD approach does not work well or it’s hard to automate lots of tests. BDD might help at these projects to help describe complex test cases in a simple format. It can thus allow to focusing on the big picture instead of getting lost in small details.

One of the biggest strengths of BDD is that when using this methodology customers get involved in the software development cycle from end to finish. In the classical approach, conversation between the customer and developer in the software development life cycle only tends to happen at the testing phase. If this conversation starts sooner than the testing phase, issues due to previous miscommunication will be identified sooner and fixing them will cost less.

BDD brings this conversation to the very start of the process by having the customer defining the user stories. If communication is critical with your customer then implementing BDD – or at least some methodology that helps the customer be involved from start to finish – is an option to be seriously considered.

To sum it up, BDD is a methodology that is quite fresh and gaining more and more attention. Tools in the .NET world are not really mature but they’re constantly evolving. The principle however I think is really viable and if you’re working on larger projects or on special fields where TDD does not deliver satisfying results then BDD just might be a better option for you.

Tags: ALT.NET, BDD, Cucumber, NBehave

This entry was posted on Wednesday, November 11th, 2009 at 8:58 pm and is filed under .NET, Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.