ToJans edited this page Sep 13, 2010 · 3 revisions
Clone this wiki locally


This is a small document explaining why certain design decisions were made in Aubergine, and what the advantages could be. Please note that I am by no means an expert on BDD; on the contrary, this whole application has been developed to get me started on BDD. I must say that it has been a very valuable experience already.
The trigger for this document was actually a tweet from somebody saying that there were currently about 25 .net BDD frameworks !!!

The format of the stories : plain text, very loose

First things first : I prefer to give as much freedom as possible to the domain experts, since they always seem to bend rules if you do not give them a really flexible framework.

My initial inspiration for Aubergine came from MSpec, which is a .Net BDD framework that has gained a lot of attention lately. While I have been using it in the beginning, I had a few issues with it. Since I have always been a little hard-headed, I decided to write my own.

In the initial versions of Aubergine the user stories needed to be translated in a .net class according to certain conventions. In later versions I became heavily inspired by Cucumber, so I switched to a text/story and a separate context- and DSL class. The main reason to choose for this approach was giving the Domain experts the option to alter the stories, and let them test themselves if their stories ran or not. If you add a compile step, this is not possible.

Next to this I wanted these stories to be very flexible, so that a user and developer would have the ability to add it’s own extensions the way he/she wants it to (f.e. add some kind of a pre/post parsing step ). This would also give me the ability to make my framework very flexible.
After looking at stories, I realized we did not need all the mumbo-jumbo of space-interleaved blocks etc.; I just take a look at the beginning of a line, and depending on the current parsing context we are in, I either parse the line, or pass it on to another parser.

Using this approach I could also easily add the data tables (not supported in a lot of .Net story frameworks) and story givens without much hassle.

While this makes the whole story concept rather easy to adapt to needed features, it will also allow me in a later phase to allow plugins for other things,f.e. one could write a plugin which parses a line that looks like this :

If this story is ran send the email of this report to the subscribers.

Currently the option to define assemblies and contexts in the stories instead of on the command-line is implemented using such a plugin. An example :

Define a browser using Be.Corebvba.Aubergine.Examples.Website.Contexts.BrowserContext from Be.Corebvba.Aubergine.Examples.DLL

Story Make sure my website gets enough visibility
Is about a browser

As a website owner I want to make sure that I get enough visibility So that I can get enough traffic Scenario Search results for ‘keywords’ on searchengine should contain ‘’

Please note that I just skip the lines without known keywords, so the whole “as a” part is actually never processed.

The DSL-implementation :

The whole DSL implementation is based on a context instance class with methods having a “DSL” attribute. This makes the syntax very flexible, while keeping it maintainable. An example :

[DSL(@"I transfer (?<amount>.+) from (?<from>.+) to (?<to>.+) with (?<user>.+)")] void transfering_xm_from_a_to_b(decimal amount, Account from, Account to,User user) { LastStatus = AccountService.Transfer(user,amount, from,to); }

This method will execute if the current spec is matched to the regex. The output of the parameters is reparsed until no more parses are available. If you call this function this would also call the following (if you use the correct syntax) :

[DSL(@"the user (?<username>.*)")] User GetUser(string username) { return rUser.Find(username); }

Which makes the stories extremely flexible, and offers some kind of a “pseudo-programming language” to the domain expert. It also handles the problem about type conversions.

The test-runner : a simple console application

While almost every developer knows what unit tests are, most of the domain experts don’t . If it comes to running unit tests, there’s probably even less domain experts who know how to do this. Next to this, in the bigger companies the domain experts do have restricted access to their pc, so installing a unit testing framework or a ruby environment for a domain expert will most likely not be allowed. If you have only one small executable together with some DLL’s and a few text files, it might be easier to get it accepted.

However, I do agree on the fact that a console runner might be a bit too hard for most domain experts, but using a few batch files, one could easily set-up some kind of an ‘easier to use’ testing framework.

A gui will probably come later, and will be using the same principle as most unix applications, i.e. just a wrapper around the console.


While Aubergine is by no means the framework for BDD in .Net, it does solve some of the problems mentioned in my manifest. Please take note that this is my personal opinion, and one could easily have another opinion on it. Please do let me know what you think.

Enjoy !!