Test Driven Development

By practicing test driven development, you can enjoy several benefits to your project.

First of all let us look at the three laws of test driven development:

1. You are not allowed to write any production code unless it is to make a failing unit test pass

   • This ensures that all production code we write has a good reason to it, and a test to test it.

2. You are not allowed to write more of a unit test than is sufficient to fail

   • This ensures that the problems are solved bit by bit. And at each point in time, there is only one thing that can be wrong, or not working. This makes it easy to go back to a previously working state. This also reduces time spent in debugging.

3. You are not allowed to write any more production code than is sufficient to make the one failing unit test pass, in the most simplest way.

   • This ensures that the code we write is the simplest possible code. Moreover if that "simple" code is not enough to cover original requirements, it is an indication that we need to add a new unit test. This ensures that the tests are complete, and can even serve as a documentation for the code.

By practicing all these here are the benefits that are introduced:

• Zero debugging time. We only write code to make one failing test pass, as a result, we can almost always know what is wrong because it must be in the code that we just wrote in trying to make that test pass. This greatly reduces debugging time.

• The tests serve as a documentation of what the code does and how to use the code. This is useful for a new developer who just joined the team.

• The tests give us confidence to refactor fearlessly. We can refactor anytime and use the tests to verify that everything is still working.

• Since every line of code is written due to a failing unit test, if someone wants to know what a particular line of code does, then he just has to put in a obvious bug and see which test fails! It will point him to the exact purpose of that line or chunk of code!

• Since we write our tests first, we are sure that our code is well designed to be testable. This generally means that modules are decoupled properly and utilize proper dependency injection to enable easy mocking.