On Feb 4, 2008 1:20 AM, Pat M. [email protected] wrote:
For some info on why BDD kicks TDD’s butt …
Woah!
I find this deeply disturbing. I believe your heart is in the right
place here, so please don’t take this as a personal attack, but this
statement reflects a view that I see expressed quite often and I think
we need to set the record straight on a few things.
To be clear, what I’m about to express are my personal views and may
not align with those of Dan, Dave, Aslak and others who are driving
the BDD discussion.
This is not a contest between approaches.
BDD started off as a thought experiment: an attempt to find a better
way to talk about TDD, because some of us who felt like we got TDD
wanted to help those that we felt didn’t. The process (at the object
level) was (and remains) the same. We were just playing with words and
constructs to better evoke what we believed to be the essence of TDD:
driving out implementation with executable examples of the expected
behaviour.
Over time BDD has grown to include TDD (which is about the behaviour
of objects) and an approach to Customer Acceptance Testing (which is
about the behaviour of systems) called Acceptance Test Driven
Planning. It’s evolving into a full-stack agile process, so at this
point trying to compare TDD with BDD doesn’t make sense since the
former is part of the latter.
But even back when BDD was only about objects, it was still TDD at
it’s core. Not better than TDD. Not even different from TDD as
practiced by those who really understood it.
So while “TDD as intended” kicks “TDD the way many do”'s butt, and
while BDD may help people to see the light, that light still belongs
to TDD.
FWIW,
David