Are Story Runners appropriate?

This post was originally published here.

Scott recently voiced his opinion on the validity of story runners (i.e. the xBehave tools) in an agile shop.  First, let me say that I sincerely appreciate the passion Scott has for BDD, and it’s that passion that will drive the community forward.  Second, in recognizing that passion, I won’t respond to comments about technology fetishes and code-sturbation for now, but I do honestly understand the concerns behind them.

Scott sees a tool in search of a problem, and in completely disagreeing with the problem it’s trying to solve, questions the motivation of those developing the tool, which he sees as seemingly selfish and egotistical reasons.  From that point of view, again, I completely understand Scott’s concerns, and luckily I have a Bellwarese translator to get to the heart of those concerns.

I did feel it unfortunate that the BDD conversation revolved around tools.  BDD is far too nascent to argue tooling, and instead the discussion should have focused getting the language, values, and concepts right.

So Scott’s core question is:

Are Story Runners appropriate for executable requirements?

As an aside, not once in my experience have I had a BA come up to me and say “hey, while you’re delivering this, it would be great if you had some automated tests for it too”.  I’ve never had anyone from the business ask me to use any kind of automated testing tool, such as NUnit, FitNesse, NSpec, or NBehave.  These tools will always be pushed by geeks, as it is the geeks that see the value of these tools first.

For me personally, capturing stories in code was never about traceability.  Specifically, the tangible benefits Joe and I saw were:

• Providing a more complete description of the behavior of the system
• Unit tests too granular

• Even specifications can be difficult to organize

• Stories provide a better overall, macro view of the system
• Executable stories remind us of our final goal
• For us, the final goal isn’t the unit tests, but that the story is satisfied.

• Capturing in code helps direct us towards that final goal

• Executable stories can help capture the conversation
• Executable stories can help shape our domain model and infuse the ubiquitous language into the system

The more appropriate venue for our discussion was Jeremy’s topic Sunday on executable requirements.  Stories are part of BDD, as we can all agree, but should stories be used as executable requirements?

The result from the discussion was “let’s see, as nothing else has worked great so far“.  Start with stories, end with stories.  Stories -> Scenarios or Aspects -> Specifications (NSpec) -> Unit tests (NUnit) -> Integration Tests (FitNesse/NUnit) -> Functional/Acceptance Tests (FitNesse/NBehave).

I do appreciate this dialogue, as only through debate with the truly passionate can clarity be achieved.

p.s. please don’t suggest exploding laptops, we’ve had enough problems with that here…