TDD vs. BDD: or why can’t we all just get along?
Join the DZone community and get the full member experience.Join For Free
i was listening to another good hanselminuets podcast - understanding bdd and nspec with matt florence and amir rajan . as always it was a good and informative show. towards the end of the show one of the interviewees (i think it was amir) explained why bdd is much better than tdd…
for those of you who do not know what i’m talking about – tdd is t est d riven d evelopment (or design) and bdd is b ehavior d riven d evelopment. tdd is more “low level” talking about unit tests and integration tests and how to write code that tests code while bdd is about specifications and behaviors.
each methodology has its own frameworks that help write and run tests (or specifications) that make sure our code does what it meant to do.
am i the only one that sees a resemblance?
you might argue that one is better than the other till you blue in the face it does not change the fact that they are two sides of the same coin.
there are differences – bdd is more “high level” dealing with specifications and was intended to be used by domain experts as well as developers – although i’m yet to find the product manager that would write specifications. on the other side tdd is developer oriented and intended to be used by people who write and read code daily.
but regardless of these differences i don’t really see a reason why you should choose one over the other. i confess i use tdd and unit/integration tests in most of my projects but i do have several projects where i use both. i like the fact that i can write unit tests as well as specifications – because i need to test both. i also find myself using unit testing framework (i.e. nunit) to write more “bdd’ish” kind of tests.
and so i don’t really understand why one is better than the other. mainly because i prefer to use both – when possible.
and if you never tried bdd (or tdd) before i suggest you do and see for yourself.
Opinions expressed by DZone contributors are their own.