Understanding BDD motivations better

21 October 2009 (Wednesday)

I posted earlier some reservations about BDD – largely based (as I now understand) on the declared motivations of some BDD practitioners (ringleaders even) that BDD tools enable customers to write tests (and also it felt like another software practice that swept up ‘requirements elicitation’ as a simple step to do before coding (and even if you do this iteratively, you are still doing ‘spiral’ development, but certainly not doing agile development).

However, reading at the interesting pairwithus:

When we first heard of the “Given When Then” structure for writing acceptance tests, we knew instinctively that it was a better way of writing executable examples (wrapped in the structure of an automated test to reduce ambiguity). It was presented by Dan North and Joe Walnes at XP Day 2006

Since then a number of frameworks have risen up using that structure. Many of these can be written in plain text. Despite this, there are still many teams using FitNesse and the new table parsing Test System called SLIM.

Unfortunately, the way FitNesse is used is, too often, as an .automated testing. tool rather than as a tool that documents desired software behaviours in a customer-friendly way (using automated tests). There is a substantial difference in practice, despite such subtle difference in the words.


I notice that they are emphasizing BDD-style notation (Given/When/Then) into customer readable rather than customer writable tests. Even if “customer readability” is still a hard target to actually achieve (i.e. can I imagine any of my customers actually reading my tests?) it is a lot more plausible than getting them to write the tests. And anything that focuses on test-readability can’t be a bad thing.

Okay, so sounds like it’s time for me to focus on getting my tests more readable, and learning Given/When/Then style together with some explicitly BDD toolset or other (guess that’s cucumber for a Ruby/Rails context, right?). And I figure I better throw in Selenium or WebDriver into the mix too, cause my ajax testing strategy is just creaking at the seams…

%d bloggers like this: