No, BDD was an adaptation of TDD to be something different, this is just an explanation of TDD to people who don't understand what TDD is, and don't understand how you can test code before you build it (which, obviously, TDD doesn't do -- it builds executable specifications for what a unit of code will do before its built.)
BDD is similar, but focuses on higher levels units of change that TDD does, and focuses on accessibility of the specifications to customers / analysts.
Well, I'm not trying to snark ... I just don't see the distinction. When BDD first came out, it was based on the premise that, yes, we're really just doing the same thing as TDD, but we're using better words. We use "spec" instead of "test," for example. And merely the act of using more precise words has a deep effect on how we think, and therefore that alone is worthy enough of a basis to launch a new movement called "BDD."
I liked TFA for its clarity and I believe it is accurate. But it still feels to me like it articulates the same thing I read when BDD was new. I wonder if possibly the author has rediscovered, independently, the same thing that motivated the launch of BDD in the first place.
When BDD first came out, it was based on the premise that, yes, we're really just doing the same thing as TDD, but we're using better words. We use "spec" instead of "test," for example.
BDD is a higher level framework (focussed on acceptance test rather than unit test) and addresses relationships in a broader scope (customer to dev team) than TDD tends to. Its not just a rephrasing, its a further development.
BDD also focussed on how tests should be expressed based on the combination idea of being executable specs and the idea that that analysts/customers should be involved in, at least, reviewing them.
So, some of the things in the article here might be related to the thinking at the roots of BDD (heck, it even uses the word "behavior driven design"), but its making points about TDD that are outside of what BDD is focussed on.
Comments
No, BDD was an adaptation of TDD to be something different, this is just an explanation of TDD to people who don't understand what TDD is, and don't understand how you can test code before you build it (which, obviously, TDD doesn't do -- it builds executable specifications for what a unit of code will do before its built.)
BDD is similar, but focuses on higher levels units of change that TDD does, and focuses on accessibility of the specifications to customers / analysts.
Well, I'm not trying to snark ... I just don't see the distinction. When BDD first came out, it was based on the premise that, yes, we're really just doing the same thing as TDD, but we're using better words. We use "spec" instead of "test," for example. And merely the act of using more precise words has a deep effect on how we think, and therefore that alone is worthy enough of a basis to launch a new movement called "BDD."
I liked TFA for its clarity and I believe it is accurate. But it still feels to me like it articulates the same thing I read when BDD was new. I wonder if possibly the author has rediscovered, independently, the same thing that motivated the launch of BDD in the first place.
BDD is a higher level framework (focussed on acceptance test rather than unit test) and addresses relationships in a broader scope (customer to dev team) than TDD tends to. Its not just a rephrasing, its a further development.
BDD also focussed on how tests should be expressed based on the combination idea of being executable specs and the idea that that analysts/customers should be involved in, at least, reviewing them.
So, some of the things in the article here might be related to the thinking at the roots of BDD (heck, it even uses the word "behavior driven design"), but its making points about TDD that are outside of what BDD is focussed on.