Register now or log in to join your professional community.
Test-Driven Development
TDD is Contain five different stages:
First the developer writes some tests.
The developer then runs those tests and (obviously) they fail because none of those features are actually implemented.
Next the developer actually implements those tests in code.
If the developer writes his code well, then the in next stage he will see his tests pass.
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.
The cycle can just continue as long as the developer has more features to add. A flowchart is given below of this cycle:
Behavior-Driven Development .. (Bdd)
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.
Whatever the actual definition is, it doesn’t matter that much. The main thing to know is that BDD is meant to eliminate issues that TDD might cause.
In contrast to TDD, BDD is when we write behavior & specification that then drives our software development. Behavior & specification might seem awfully similar to tests but the difference is very subtle and important.
