@Scott. Thanks for the positive comments, it was yours and Joe’s blogs that I’ve been reading for the last little while. The .Net (and Ruby) community seems to be more active in this area than Java’s.

I make the distinction between “code” and “story” levels as I find that current “BDD” frameworks are focused at one or the other (unfortunately not usually both). Hopefully this distinction will go away after a while (we’re already seeing RSpec/RBehave), and we’ll see frameworks support both (all) levels.

I personally came to BDD after seeing RSpec, and seeing how it overcame a lot of the problems I’d had test driving. From that point of view I created Instinct to help in driving behaviour from a developer’s POV. It’s only been in more recent times that I’ve seen the emphasis (on blogs at least) shift back to story level specification. I think this is a *good thing*, however at some point developers need to be able to specify behaviour at their level.

We are all customers of our own code and we all need an API that provides the right language. Code level frameworks provide this for the developer, story level frameworks for a discussion between developers and customers.

Is it the example I’ve given or the categorisation that you’re not comfortable with. Upon re-reading, perhaps it’s the lack of context?

I’ve no problem with BDD examples being presented in context with the stories that drive them, however I felt the examples (possibly presented out of context) were appropriate for the audience of OSDC. Also, there is every possibility that these high level stories will drive a large number of lower level artefacts (classes, etc.) that may be technical in their nature, and not something of interest to a customer. Unfortunately, I don’t believe that the current story level APIs provide the flexibility nor readability required by developers when specifying the behaviour of this code.

I’m not particularly enamoured of the example, I think a stack is a pretty poor example for BDD, so I’d be happy for a better one!

That said…

You’re categorization of the “unit level” specifications is misleading.

There’s no value in talking about these “unit level” specifications in absentia of the stories that caused them to come into existence.

The spec on the stack object is typical of unit testing and TDD tutorials and does negative service to BDD practices since unit testing and TDD examples are often presented out of context with their stories.

I think you’ve just fallen into the same old TDD trap except that here you’re doing it with a BDD-oriented tool.