Test Driven Development – Clean Code Video

While watching the episode 6 of the clean coders video I noted down some important points.

• Design and Code rots lead to fragile, rigit and in-mobile code base. Debugging becomes difficult, estimates mount and implementing any new changes becomes difficult. Uncertainity in the code increases.

• Maintaining a test suite with a high code coverage has below benefits

1. Keeps defects under control 
2. Gives us the courage to change the code in order to clean it 
3. Unit tests act as code examples for your API. They are low level design documents. For e.g. The test cases helps us to know all the possible ways to call a particular API. 
4. Writing tests first, makes the production code testable. To write unit tests you would have to make your functions decoupled from each other. This leads to an improved design.

• TDD is a discipline and has a set of rules. Below are the three important rules

1. Don’t write any production code until you have written a failing unit test 
2. Stop writing any more unit tests than the ones which are sufficient to fail. Not compiling code is failing. 
3. Don’t write more production code than is sufficient to pass the current failing test.  

These three laws suggests that we should be constantly switching between production code and junits. Add a failing junit, add code to pass that junit, and then add another failing junit and so on.  
Following these three laws of TDD could reduce down the debugging time by a factor of 2. 

• Its important to trust your test suite and this trust will come only when the above three laws of TDD are always followed. Writing tests after completing the code is not only boring but ends up in being just a procedural milestone because you already know that the code works since you have tested it manually . The developer takes shortcuts at such times and hence leads to a low code coverage with the junits and less trust.

Advertisement