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.
