Test Driven Development
My first experience with Test Driven Development (TDD) was about 2 years ago, when I worked on a project to develop h.264 codec at my previous company. At first, the notion of creating the test before writing the code seemed confusing. How are we supposed to test the code that we haven’t written yet ? That was the first question that popped into my mind when my co-worker explained the process.
After I actually applied TDD, the idea became more obvious to me. In TDD, because the test was written before the code, it will obviously fail. Our next step is to write the code that will make the test pass. After all the tests pass, it’s time to add another feature, that we state in new tests. These new tests will pass after we write the code for the new feature. This process will repeat until we implement all of the features in our program.
In TDD, this test is called unit test, which verify the correctness of one module or class. This unit test should not be confused with acceptance test, which verify the behaviour of the whole application. Unit tests will grow as we add new class and functionality, and should be run every time we build the application.
One of the advantage of TDD is, as we add new code, we will be informed quickly if the newly added code break the functionality of previous code, indicated by failed test(s). TDD will also help the programmer to think about how the interface of the new class or module should look like. To make the class or module easy to test, it should be made modular and less coupled, which in turn, will improve the design of the whole application.