Andrew Stopford's Weblog

Use it, teach it, love it... :0)

Looking into it, after seeing Lee Brandt's talk at the St. Louis Day of .NET

Yes and yes! I primarily use the context specification variant of BDD, but I find the focus on the behavior of the system (particularly from the end-user perspective) more valuable than names based purely on implementation. I've also found that it is easier to explain to newcomers because they don't get caught up on the whole "test" in TDD, but instead can focus on it as a design tool.

Makes testing more natural imho. I also noticed that it is easier to explain why we need testing to our business and functional people.

Pingback from  Dew Drop – September 9, 2009 | Alvin Ashcraft's Morning Dew

I'm interested in BDD, but I have never used it.

Interested but still reading about agile and solid at the moment

Yes to Context/Specification-style testing. I don't even use the term BDD much, these days (too loaded of a term). Or, if I want to laugh smugly to myself, I say I'm practitioner of Bellware-Driven-Development.

What's important is the break from the traditional TDD "Class/System Under Test" model of thinking that tends to lead to tests that talk about and verify an implementation, and not really *desired behavior* of a component. Any experienced practitioner of TDD will say as much (as they've learned from pain and experience), so really this is a codification of what experienced TDD'ers already know.

Also, I feel less squeemish about testing interactions between systems as an exploratory, implementation-phase exercise when doing Context/Specification. The tight 'red-green-refactor' cycle in TDD dictates one test -> one feature or thereabouts, but that isn't strictly neccesary in Context/Specification, where you "stub" a number of specifications for behavior you want, and work through implementing the specs as you add the functionality.

Context/Specification (for me) is also about revealing the utility and use of a component through easy to read/meangingful code in the context/because segments (the Arrange/Act portion of a traditional TDD tests). Once again: I think more deliberate attention is paid to this, compared to traditional TDD, even though learned practitioners will tell you that this is something they try to do.

Anyhow, its definitely improved the way I think about testing, but my process/thoughts on the matter still evolve constantly.

I don't get it, seems like the end user tells you what they want in their own words\way (even if that logically contradicts itself as is often the case) and you make all other decisions from there on yourself, thats not a methodology at all. I do it all the time, but its usually infuriating, am I missing something?

BDD is just TDD with different method names. Barely deserves mention.