BDD beginner’s stumbling block

I should probably add that this is a stumbling block that *I’ve* run into, which doesn’t mean anyone else will.  But it is *my* blog, so that should be obvious.

I have started to use BDD on a greenfield project because I hate it.  Well, that’s not quite accurate (since it would be pretty dumb if that was the only rationale behind it).  I like a central idea behind it.  Well, I don’t hate it.  Anyway, the central idea is that you can write up specifications that are in more or less straightforward English, and using Machine.Specifications anyway, you get this nice, pretty (well, not really pretty, but legible) report that lists out which specifications have passed, which ones have not yet been implemented, and which ones fail.

What I’ve always hated about BDD is that the examples I’ve seen all try to force specifications into As either  a/I want/So that or Given/When/Then format.  It’s like trying to do software development through nursery rhymes.  “See Spot run.”  Even worse, it seemed as if you had to actually force all of your specification code to follow one of these formats.  For whatever reason, this always has rubbed me the wrong way.

Machine.specifications, at least in terms of how I’m using it in my ignorant neophyte manner, seems to allow a little bit greater flexibility in how you structure the language of the specifications.  Within the C# code, you still have to use the framework within its confines, and there’s that great ‘phallic symbol’ syntax you have to use, e.g., “= () =>”.  But it seems to be an improvement.

And, as BDD is supposed to do, it does help you to focus.  A business partner came up with a domain concept that was somewhat sophisticated (details irrelevant) and he described it by using examples.  Now, in the good old days of total BDUF, it would be natural to take the concept and then try to generalize it to all possible permutations as part of the design process.  But by focusing the specifications to test the examples given, you write the minimal code necessary to do so.  If another example comes along that ‘breaks the model’, you then have to refactor the already existing specifications.  Rinse and repeat.

But, one thing I’ve found myself doing in the initial stages, with specifications that I have designed as being a domain expert, is constantly renaming the specification classes so that the report is more legible.  Now, to a certain extent, this is part of the point.  As you clean up the language of the specifications, you may find yourself discovering that your specifications aren’t quite right.  And this, I think, is a good thing.

However, it also can lead to a lot of re-writing of the class names even if the assertions themselves stay the same.  You can spend a lot of time doing this.  At least, *I* can spend a lot of time doing this.

Hopefully, as I get more practice under my belt, this will lessen.

posted on Saturday, June 27, 2009 7:41 PM Print
# re: BDD beginner’s stumbling block
Victor Kornov
6/28/2009 9:52 AM
A couple examples "of how I’m using it in my ignorant neophyte manner" would be great. So other newbies could learn from your mistakes ;)
# re: BDD beginner’s stumbling block
6/29/2009 10:41 AM
I'd recommend watching Rob Conery's BDD/Kona web cast at:

You might want to skip through the introductory stuff, as I don't think it does the best job at explaining BDD. It's better to watch how he redoes his tests into spec format. I'm using mspec sort of as he does it.

Post Comment

Title *
Name *
Comment *  
Please add 7 and 4 and type the answer here: