Test Driven Development (a.k.a TDD) is one of the most intriguing feature of eXtreme Programming(XP) family. It has its own share of critics and followers.
However, there is a general consensus that TDD, if followed, produce codes with better unit tests with (probably) reduced bugs.
Despite the popularity and the general consensus about benefits of TDD, it’s still considered as an extra curricular coding activity than a mainstream one. There might be various reasons for the same, but as a developer I found that the most obvious reason is the misconception about the core principles behind TDD and how to use them.
So I’ve decided to decode the TDD for the benefit of people willing to pursue it. I like TDD and practice it a lot, but holding non religious views on it.
How to start for TDD
Here are the four steps required to do the TDD which one should remember by heart
- Write “enough” failing tests before writing the production code
- Write production code to pass those failing tests
- Re-factor the code, if required.
- GoTo Step — 1
Step → 1 : Write “enough” failing tests before writing the production code
