What TDD won’t tell you and why BDD is equally important?

Most of us think Test Driven Development is a cycle of test, implement and refactor. In reality its the freedom to start working toward your solution before you can map it all out.

It’s the freedom to make changes knowing your tests will alert you if you have violated a previous assumption that you have forgotten.

Since TDD forces you to write test first, it also forces you to think about how you want to use an API, because that is the very first thing you write down. This is a good thing and it leads to more usable APIs.

TDD also forces you to factor out dependencies in order to be able to mock them. Thats the other point where TDD encourages good design.

Now here comes the twist : There is more to software design than just nice to use APIs and good principles.TDD does almost nothing for you in order to find a good solution for your problem. 

TDD won’t tell you following -

• Can your domain model represent all the cases needed by the business?
• Which of all the design patterns would help you? Is there any well known algorithm you could use to solve your problem? 
• Does the problem become trivial once you approach it in a functional way?
• Is recursion a solution or a dead end?

Ultimately one has to understand the problem and know lots of possible approaches to a problem in order to design software well. There is just no way around it.

Once you have the solution in your mind, once you know the basic data structures and algorithm you going to use, TDD will help you to implement it in a clean, well factored way.

Having said enough about TDD I would like to now shift my focus on BDD (Behavior Driven Development) and its real value.

TDD is more “low level” talking about unit tests and integration tests and how to write code that tests real code while BDD is about specifications and behaviors.

In TDD we talk about Arrange Act Assert while in BDD we have Given When Then

There are clear cut differences between both. BDD is more “high level” dealing with specifications and was intended to be used by domain experts as well as developers

As a matter of fact one should write unit tests as well as specifications – because we need to test both.

TDD is described by a basic red-green-refactor cycle, I have come across this interesting checklist on dzone which is written in the form of questions we should ask ourselves while going through the different phases of the cycle.

Happy Testing :)