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...
.png)
3 comments:
> BDD is far too nascent to argue tooling
Like hell it is! That sounds like a justification to continue the social experiment that comes from double-entry capturing stories in a more rigid medium than the stories themselves.
Stories don't belong in test code. Putting stories into test code is where you're indulging your technology fetish. Everything else is perfectly fine in my book.
By the way, are you guys using specs at the unit level, or just doing the requirements language thing at the macro level?
@Scott
I meant that the initial dialog was better served talking about BDD than arguing tools. More discussion around "why the change in language bro?" would have been nice. The social experiment discussion continued the next day at Jeremy's talk.
I would qualify "stories don't belong in test code" to be "stories don't belong in test code if your stories are solely ethereal beings". For some shops, the story IS the requirement, and that's where the value lies.
Specs for us stop at the unit level, when the business can no longer provide direction. I wouldn't say "macro" level, but at the business entry points into our model, namely our application and domain layers.
When the business has specifications, we write specs. When they don't, we write unit tests. We have a clear separation between "specs from the business" and "tests for the scaffolding".
Story runners at least as automated integrated tests can only be a good thing...
my 2c
Post a Comment