I’m a little bit confused about BDD. I’m doing TDD currently.
My question is whether BDD is complementary to TDD or it’s a whole new thing and my team should do both TDD and BDD? Or is it enough to do just one or the other?
3
By definition, BDD is based upon TDD and is a refinement / extension / specialization of the latter.
is it enough to do just one or the other?
According to the above, you can’t do BDD without TDD.
In general, there is no one-size-fits-all answer: do what suits your team and your project the best. Feel free to experiment with new ideas, pick what works and drop or change what doesn’t.
Moreover, this is not an all or nothing question: you can do TDD enhanced with specific ideas from BDD which you feel are a valuable addition to your process. For example, I adapted the “should” naming convention of unit tests in my practice because I find it makes my unit tests more readable and expressive.
3
This discussion has been very active lately in the software development community. For me at least BDD has caused a mind shift, a shift that emphasizes software behavior over implementation. Bringing the ubiquitous language in all parts of the development process is of great benefit and BDD teaches that. BDD has a broader audience tester, managers, analysts.
Rachel Davis has a nice explanation of BDD=”Shared understanding by discussing examples”. So describe what you want the system to do and talk about some examples. If you want to read more on this topic check out this discussion on one of the father’s of BDD blog: BDD is like TDD if …
I think the BDD/TDD systems have undergone a change in what they were originally about, but nevertheless, they still have their uses and are complementary. TDDs via unit tests are very popular today, but adding BDD via something like Cucumber allows you to drive your components in a more user-focussed way. I think of them today as TDD being ways to test the objects, and BDD to test the applications/components.
You can still do BDD using Unit test tools (as I think it was intended) by writing your tests and then creating objects to fulfill them (ie not just as a method level granularity), but with ‘story based’ testing tools, you can create higher-level tests that are a little more evolved than using unit-test tooling.