Question

I recently heard of BDD and found it very similar to TDD.

Which of these two do you use (if any)?

and which are the pros and cons of each?

Was it helpful?

Solution

I'm very much of the BDD = TDD done properly camp. If you're doing TDD as originally described by Beck - and practised by many - then there is essentially no difference.

What BDD brings to the table is some interesting variants on the language used to describe the process. By using alternate terminology in the descriptions of the process and the tools BDD folk hope to encourage better practices - a laudable goal.

I've been doing TDD for so long now it's hard for me to judge whether this actually helps. I think (hope :-) I've already learned many of the lessons that BDD tools/language encourage so that they don't seem to provide much extra value to me. Of course YMMV - and I've not done a whole "real world" project using BDD tools - so I might be taking my personal experiments and extrapolating too far.

I'd guess that BDD tools/language may be more useful to folk being introduced to this way of approaching development - since they avoid the whole confusion with "test" being used in the more traditional sense. I've not done this myself yet - and would be interested if folk here have had any such experience.

OTHER TIPS

BDD is similar to TDD but with a different mindset. In BDD you're trying to create executable specifications instead of tests. This is mostly accomplished by using a different vocabulary but similar mechanics as TDD.

BDD seems to be a reaction to a lot of cases where people claimed to be doing TDD but were writing integration tests instead of unit tests. BDD people thought talking about tests was misleading and so tests became specifications. This seems a bit metaphysical but there are some good ideas behind it.

BDD is all about running the scenarios. Similar to TDD we will test each and every scenario as a story.

The story will be explained by the customer.. basing on the storyline the scenarios will be written. Tools like CUCUMBER made it easy to write scenarios.

TDD and BDD are pretty much the same. The difference is how we explain it, and therefore how succesful teams end up being in making it work for them.

BDD builds upon TDD by formalising the good habits of the best TDD practioners. TDD is a developers tool or guide to write good software and BDD is a good tool to help outside in development with more involvment from the bussiness as it is developed using a ubiquitous language.

My experience is that BDD helps on collaboration, and the use of business-readable, executable specifications helps to build a shared language when everyone in the team is involved in writing documentation that describes what the system should do. This helps the whole team to learn the language of the domain together.

BDD is what it takes to make TDD succeed.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top