TDD is low level, where you write unit, functional and integration tests that fail in order to write code that makes them pass.

BDD is higher level, where you write "stories" that describes what the user needs to do and why in order to implement functionality that makes them pass.

You generally use them together, starting by writing a story for a feature and then moving down into TDD to actually create the implementation. The lower level tests verify that your code is correct, and the higher level stories ensure that your system behaves according to the user's requirements.

Test-Driven Development When I first heard about TDD, the idea seemed to be pretty simple. Just by doing a little word swizzling, obviously TDD is when you have tests that drive your software development. If we were to unpack the definition of TDD a bit more, we’d see that it is usually broken up into five different stages:

1- First the developer writes some tests. 2- The developer then runs those tests and (obviously) they fail because none of those features are actually implemented. 3- Next the developer actually implements those tests in code. 4- If the developer writes his code well, then the in next stage he will see his tests pass. 5-The developer can then refactor his code, add comments, clean it up, as he wishes because the developer knows that if the new code breaks something, then the tests will alert him by failing. Behavior-Driven Development Alright, so what is BDD you ask? Well that’s where the line gets a little fuzzy. Some people will say it is similar to TDD, others will say that it is just TDD but with better guidelines, or even a totally different approach to developing.