ISerializable - Roy Osherove's Blog

Pingback from  Dew Drop - October 5, 2008 | Alvin Ashcraft's Morning Dew

I only just came across this realisation last week as well. I had thought the actual BDD concept was just for acceptance tests - JBehave is an example of a library where this is the case.

I have been writing unit tests in a similar way (see www.markhneedham.com/.../bdd-style-unit-test-names for more details) but there is no framework as such involved, just plain old NUnit or JUnit

Yup thats an important distinction and by not making it clearly BDD has become very confusing. To me the two variants are:

1. xBehave/Dan North/Acceptance testing

2. xSpec/Dave Astels/Improved TDD

This is utterly, completely, and irresponsibly inaccurate... but everyone is repeating the same mantra after doing "research", so no harm, no foul.

If your research involves merely reading what the parrots on the web are parroting, then you're bound to come to this conclusion.  Nonetheless, it's an inaccurate and sadly misleading conclusion, and we really should be doing more tangible research rather than reporting merely on what others are saying.

Firstly what you're calling "behavior" frameworks are actually referred to specifically as "scenario" frameworks.

xSpec and xBehave are BOTH behavior frameworks.  The only significant difference is the grammar used to express behaviors.

Secondly, the differentiation of purpose between framdeworks - xBehave for functional specification and xSpec for unit specification - didn't come about because of the nature of the frameworks, but because of a concession made to Dan North who had something specific in mind with "BDD" that Dave Astels interpreted differently.

This division of responsibility of frameworks is more of an arbitrary truce between framework perspectives and is no more of a natural division than building a wall through the middle of Germany at the end of the second world war and calling one half communist and the other half capitalist.

The history of the differentiation is entirely political.  Either framework can be used for either purpose.  There is only a very small wedge of cases where either is more applicable than the other.

In case its useful I thought I'd put up a link to a blog entry I wrote a while back on this:

colinjack.blogspot.com/.../bdd-two-approaches.html

@Scott

"Secondly, the differentiation of purpose between framdeworks - xBehave for functional specification and xSpec for unit specification - didn't come about because of the nature of the frameworks, but because of a concession made to Dan North who had something specific in mind with "BDD" that Dave Astels interpreted differently."

As you say Asels/North seem to have had slightly different takes on BDD and that informed the paths they took and the resulting frameworks.

Plus I think we'd agree that focussing on the frameworks is the wrong approach, and to be honest i've done the majority of my BDD just with xUnit and tools like Watin where needed.

However I think Roy still has a point in saying that xBehave is primarily aimed for user story/acceptance testing.

Colin,

We are presently using the GWT scenario grammar for directly testing stored procedures.

My experience with both framework grammars contradicts the oft-perpetuated commentary on which problems each framework addresses.

There are indeed differences between the behaviors, and those differences can be significant.  I've yet to see anyone objectively writing about these differences in context of problems which they solve.  More often I see folks simply stating the overly-simplistic "xBehave for functional specification, and xSpec for unit specification."

This perspective is rooted in trying to see BDD through TDD glasses without the awareness that we're wearing TDD glasses, or even that TDD-colored glasses exist.

It's a question of subtle but powerful change in paradigm, and our typical inability to become aware of new paradigms because of the biases we build up when we become attached and identified with a preceding practice.

Pingback from  James Thigpen  / Capture.Exception - BDD-esque w/ NUnit or: The Ikea Nightstand

@Scott

Yeah I don't disagree, my feeling is just that acceptance testing poses a couple of additional challenges which make composition more useful.

I also feel like a lot of blog entries talk about BDD without taking much account of what Dan North described which leads to confusion, I think thats a big problem and one that I hope is gradually addressed.