Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

A Brief Statement on BDD

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.  

This entry was posted in .net, BDD, python, Rails, Ruby. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

2 Responses to A Brief Statement on BDD

  1. Dave Laribee says:

    Admittedly it’s pretty dense. I’ll try to unpack it a bit in plain English, sure.

  2. Dave,

    I gotta spend more time in New York learning how to talk New Yorker… I have no idea what you just said :) But you did say it was loose thoughts, so… fair enough.

    Could you elaborate on your definitions of:
    – specs as “class specifications”
    – behaviors are story/feature-to-code mappings
    – behaviors are provided by the code
    – how the stories modify a system’s present state
    – iteration-level stories
    – this isn’t a specification it’s a feature
    – features as a larger expression of how a user approaches as system to accomplish a piece of work
    – divorce these expressions from the BDD process
    – opposite side of an iteration
    – sequential story or “narrative” that expresses an atomic or composite workflow

    I guess I’m looking for a complete re-statement of the post without the loose thoughts :) There’s a lot of a-priori ideas here that I don’t think made it out of your head in the writing.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>