If you have been using TDD (Test Driven Development) or even maintaining unit-tests at some level, then probably you have already been using these tests as a means to express the business requirement. Writing unit tests before writing the actual implementation code is undoubtedly a very good exercise to brainstorm and understand problem before making an attempt to solve it. But for developers who are writing these tests, there is always a chance of missing out something of business importance or misinterpreting a business requirement. In other words, though these tests might be good for many things but they hardly make any attempt to bridge the age old gap between the business needs and the code development.
Another ailing thing about TDD is the name itself. ‘Test’ driven development is hardly about testing. It has never been about doing the tester’s job. Many people would say TDD is and has always been about good design. I do not completely agree with that either. Good design is a very good by-product of TDD, but that’s not the primary purpose of TDD. The very name and the nomenclature around it, words like Test, Assertion etc, influences the brain (Sapir–Whorf hypothesis) compels it to think that TDD has got something to do with testing.
TDD also requires a fundamental shift in focus as a developer. For decades we developers have been thinking about those grand software designs up-front, creating the databases, the data-access classes, the business facades, re-usable components and what not before addressing the actual business needs in small bits. TDD done right demands for a drastic change in this mindset. It requires the developer to think about the business needs first. Pick a very tiny slice from it which still has a business value and write only as much code that is required to implement this piece of business value. Really, this might not be the most intuitive thing to do for most of the developers. Moreover, this ‘no up-front design’ idea (though I do not completely agree with it) does not work in the best interest of someone like me who sell themselves as ‘Architects’. Pun intended!
No wonder so many teams struggle to get TDD right.
Due to some of these inherent problems with TDD and the huge gray area without sufficient guidelines on what and how much to test, people like Dan North came out with the idea of BDD a.k.a. Behavior Driven Development. The idea behind BDD is pretty simple. The idea is to provide a common tool and guideline to both the business and development folks. This tool/guideline would allow the business analysts and SME’s to write the business requirements (in a specified format) using english-like language. They would write the different business scenarios around the requirement. In other word, they would define the ‘Behavior’ of the system. The same tool would be able to generate or at least guide developers write the test-cases from these scenarios. The developers would implement these test-cases one by one and make all the tests go green. And TADA! In a perfect world, you have a business requirement translated into a working code.
With BDD the point really is to be able to write tests which are more relevant. Tests which matter. Tests which are derived right out of the business requirements and scenarios, coming right out of the horses mouth. BDD is about putting some more structure and discipline into the Test Driven practices you already claim to do.