Scott Bellware posed a question on the newly formed BDD list asking people's background. The list is concerned with Behavior-Driven Development but seems to have a heavy bias toward the .NET developer. This bias seems to bend the conversation towards tools, where tools mean a kind of language/platform specific technique.
So, as a BDD user, what's my platform background?
In the near past I've been pretty much 100% C# on the CLR. Lately I have some contemporary work in RoR/RSpec and Python of the Iron variety.
My BDD world view on Sunday, March 9, 2008
I see specs as "class specifications" and behaviors are
story/feature-to-code mappings that teeter on the line of business
readability depending on the particular object collaboration they
describe and, as such, are best expressed in the same language. This
belief echoes that of the construction of virtual machines, see:
the argument for Rubinius.
I think it's hard to talk about BDD in the abstract. Hard in the sense that, from the bottom up, it's hard to divorce BDD from the implementation as specifications, well, specify the implementation. For me, behaviors are provided by the code in response to how the stories modify a system's present state.
I think there's a flip-side of BDD that says iteration-level stories end up as some kind of executable specification. For me, this isn't a specification it's a feature. I tend to look at features as a larger expression of how a user approaches as system to accomplish a piece of work. In my experience it works well (on a certain class of business application) to divorce these expressions from the BDD process. We assemble stories on the opposite side of an iteration into a kind of sequential story or "narrative" that expresses an atomic or composite workflow.
Loose thoughts to be sure. While I'm always interested in growing and extending our practice, I'm finding this definition and set of constraints handy and successful in applying a BDD process across languages/platforms.