Uncle Bob describes Test Driven Development using the three laws as follows:
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test
What’s fun in solving the puzzle that’s already solved.
Let’s say we write the production code first. We complete the desired functionality. At this point as a developer, I know it works and now I decide to write a unit test case for the same. Naturally, when you know the code that you have written works, the quality of the test case in most cases would be for the sake of code coverage. In few other cases, we end up asking ourselves “How should test this?”
We all enjoy the feeling of fixing that wasn’t working earlier. TDD give the same feeling, as we write the production code we fix the failing test case.But most importantly, in Uncle Bob’s words “If you write the test first, it’s impossible to write the function that is difficult to test.“
To summarize, writing the test first is not just fun but we end up writing the code that is less complex, decoupled, and testable too.