Documenting requirements then implementing those requirements and then documenting that implementation is bad enough. Maintaining that documentation when requirements and implementation changes definitely makes documentation, generally a problem looking for a better solution. BDD to the rescue.
Not for a second am I suggesting that the necessary documentation shouldn‘t be produced or that it does not provide essential value to a project. What I am saying is that it should be easier and less laborious to produce. In an Agile environment it should also stay as close to the code as possible. Otherwise, it is likely to be out of date as soon as the first line of code is written.
Stories
When I was at Beanlogic, we covered most of our Ruby/Rails work with Rspec specs and stories. One handy outcome of running Rspec specs and stories is that a nicely formatted HTML document is generated that is readable to civilians. In fact in the case of stories, human–friendly prose actually translate into code coverage. Something we planned to do at the time was to make more use of this feature.
In order to tell good stories and for them to be most valuable to a project, the customer/owner of any project should be encouraged to produce structured stories with scenarios in a Given–When–Then format. This would of course be done in a supportive, collaborative way — perhaps via a wiki — since not all customers have the experience or skill–sets to work in such a prescribed way.
For example, a scenario that a customer operating a luxury holiday cottages website might – with the right guidance – produce the following scenario.
Given a user is searching for cottages And they provide the search term 'fireplace' When they perform the search Then the results should contain all cottages with a fireplace
Obviously, this scenario would be split into finer–grained scenarios describing the lower–level implementation.
Using BDD (and Rspec in particular) in this way means the documentation is a by-product of the development process and is intrinsically linked to the code. This means that if requirement–creep leads to implementation changes, the documentation stays current.
Not only that, what we‘ve just done is managed to get our customer to write our top–level tests for us! Surely this is FTW!
I‘m never sure of the right context in which to use FTW or FAIL or other such intarwebz expressions. On the other hand, I‘m pretty sure I overuse WTF!
easyb
Given that I am ‘into‘ TDD, BDD, Agile and all that best–practice stuff (not everyone is); and given that I even navel–gazed about a possible Java implementation of Rspec's specs, I was shocked to find that easyb had completely flown under my radar until I stumbled upon it last week. Well, I feel like I‘ve only scratched the surface, but my initial impression is good.
I‘ll be furiously trying easyb out on testing this website and SeemoreJ in the next few days and I‘ll be posting my experience here.
First published on May 20, 2009. Last updated on: Dec 30, 2009.
I'm Elwyn Malethan and this is my blog. I am an aspiring 