Catching up with the latest RailsCast, I came across the following comment:
At first, this comment seems valid, as Cucumber is pretty wordy. And if you already know your requirements, why would you write it down? Of course. It is all so simple.
TDD is great. I’m a huge proponent. But TDD alone doesn’t get me in the right mindset. What I need is BDD. I need to describe the behavior rather than just write tests. As you see, it is all semantics. In my honest opinion, if you are doing it right, TDD == BDD. When you try to extract the differences, I feel like you are grasping for straws and not trying to achieve the real goal — Describing your code through defined behaviors.
So call it BDD or call it TDD. Just make sure you doing it first, and make sure you are defining contexts, and make sure you are actually describing behavior rather than code.
This is something that I've been considering while writing test cases with shoulda, all of the test frameworks are similiar, in so much as they're all unit tests. What matters is that TDD doesn't necessarily mandate writing the test first or even what you should write in the test. You have tools like rcov & heckle that make sure you are testing your code, but what you have with TDD is retrospective of the initial work.
I helps you prevent breakages moving from version to version, etc, but it doesn't help you do the design right in the first place. BDD with rspec/cucumber is the opposite, you sit down and you scope out HOW it should work in the form of tests(specs) and then write code that conforms to those outlines.
I would argue that BDD becomes TDD as soon as the design is done. After that point you're using your BDD framework (e.g. rspec) to do TDD.
Unfortunately, I fear that 80% of the time people express that sentiment, they are really saying “It's too hard to get my brain into a BDD mindset, I'd rather just keep thinking of my tests as regression tests”.
On a semi-related note, what do you think of the movement in some Agile circles to talk about Design By Example (DBE) instead of TDD? I almost feel like DBE expresses the intent of BDD even better than the term BDD does.
I totally agree, man. The requirements need to be written somewhere, whether it's in a BDD test, or a requirements definition / technical specification document. The funny thing is, I used to write the BDD style design descriptions into simple text documents that would accompany my source code for myself when I'd code before I'd discovered BDD/TDD.
Also, what happens when we come back to the code later, and forget what our requirements were?
Sensei.