5 Comments

  • 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.

  • @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.

  • @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.

Comments have been disabled for this content.