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.