Hacker News Reader

Comment by jws | Hacker News Reader

… where BDD = Behavior Driven Development which, if Wikipedia is to be believed, is an agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project.

The second definition exceeded my jargon quota for the day:

BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

View on HN

That's a load of crap. The best definition I've ever heard for BDD is "TDD done right". This is certainly what "BDD" started out as. The idea is that the language of typical testing frameworks doesn't encourage the right types of tests (i.e. testing behaviour rather than state), and so using a package that has the right vocabulary, you are more likely to do TDD right.

There is no significant difference between BDD and TDD other than that terminology, and most leading BDD proponents in the ruby community will refuse to set it in opposition with TDD. BDD is just a form of TDD, not some separate discipline. Defining BDD without mentioning its relationship to TDD is stupid.

BDD means testing that you've delivered what the customer asked for. User stories expressed as test. This is like the architect's rendering of a building; it expresses and implies certain desired qualities.

TDD means testing that you've implemented a system which has all the significant qualities you expected. It intends to prove that the system does all of the right things and none of the wrong things on the way to delivering what the customer asked for. This is more like the blueprint of the building, making all significant details explicit.

You could practice BDD without TDD, though I've yet to see someone choose to. You can practice TDD without BDD, which I've seen many people do.

> BDD means testing that you've delivered what the customer asked for.

No, that's "Acceptance testing", and doing it without TDD is actually quite common.

... which is why you frequently hear BDD called "Agile Acceptance Testing"

Perhaps by later practitioners of BDD who have no idea what they're talking about...

RSpec itself is in fact driven by the BDD ideas - adapting the language to make "doing the right thing" easier, and focusing on testing behaviour rather than state. RSpec has little or nothing to do with acceptance testing. It is thoroughly a unit testing tool.

Liz Keogh's "Translating TDD to BDD" was really helpful to me when I was coming from a test-driven development perspective and just starting to wrap my head around BDD. http://lizkeogh.com/2009/11/06/translating-tdd-to-bdd/

Reply on news.ycombinator.com