I cannot say I am a big BDD-er. I have used it for commercial projects, mostly to define complex scenarios for complex pieces of code (a custom discount engine comes to mind) but it comes with a price tag that I am not willing to pay for the majority of tests I write (unit tests).

I am not going to describe what BDD is, philosophy, syntaxes, flavors… I am just going to mention my experience with a couple of tools one can use if developing for the .NET Framework.

A little experiment

Quite long time ago I started SharpRomans as a learning experience with some interns here at my company. The idea was to create an implementation of roman numerals using some BDD techniques in order to get rich executing documentation.
The experiment was never completed until some time ago I decided to re-launch it, this time in Github.

The interesting thing of the experiment in regards of BDD was the tool I used: StoryQ.

StoryQ

I chose this veteran framework for a veteran project and I have been quite a happy user. In fact, I generated the whole Specification section of the project wiki by transforming the resulting XML report into Markdown (not too shabby for not having touched XSLT in years).

The way the tool was used in SharpRomans was simply using the library to write tests that are run by NUnit. An example of such test could be:

As one can see in the code, it is a quite pleasant fluent interface that leverages delegates in quite a clever manner to later infer the names of the steps and the arguments and their position via the usage of underscore placeholders.

The execution of such test produces several reports. A console output:

And a “pretty” HTML report (resulting from transforming an XML into HTML thanks to XLST):

It is easy to get the code syntax right, but if one prefers using the included “Text-To-Code converter”, it is a simple WPF application that allows converting a Cucumber like syntax into .NET code that uses their fluent interface. It is a great addition.

While look any further?

As I have said, I am pretty happy with the tool. What could have taken me to evaluate alternatives?
Well, besides the sheer desire to improve and do more with less, I have had my share of complaints for which I take some responsibility for not notifying the author or submitting a patch (although, in my defense, I tried, but was too complex for the time I allocated for it).

• The code generated by the tool cannot be customized
• If one wants a different reports, one has to put with transforming XML, which is not my cup of tea.
• Stability is a double-edge sword. People might look at the activity of the project and be put off by the fact that is has not shown any activity for years

The contender. BDDfy

If one can say only a good thing about the project is that they have raised the level of documentation for other OSS projects. It is pretty impressive.

Another thing that can be said is that it covers a lot more ground, in the sense that it is more ambitious in the styles and workflows that can support. To compare apples to other similar fruits I am going to stick to its FluentAPI.

And it generates (by default) a couple of nice reports. A console output:

And the mandatory “pretty” HTML report to show off our stakeholders what their money can buy:

The API feels quite the same, with fluent .Give(), .When(), .Then() but there are a couple of key differences:

story “context” is provided as a set of attribute properties

one can have (as with StoryQ) all-scenarios-in-one-test. When everything goes alright (all scenarios pass), everything is good; but, when one scenario breaks, all subsequent scenarios are not run (unlike StoryQ). To solve this issue (and that is my opinion about it) we can easily move to a test-per-scenario (which StoryQ can’t handle) at the cost of syntactic noise in the code

And if one looks at the console output, one can see that the story part is repeated for each of the scenarios, which I, personally, don’t fancy.

So…?

They are both quite nice frameworks and both can support my way of doing BDD. StoryQ is lean and BDDfy is more powerful and its flexibility can accommodate other workflows different than mine.

A couple of nice extras that BDDfy brings to the table are:

• a nice looking metro report (that has to be configured without any sweat)
  
• an even nicer markdown report.

That might have come very handy to generate the spec for SharpRomans, which I could have copied and pasted to the wiki. But then, I would not have written this puppy (and that might have been a good thing ).