Not much time has passed since we blogged about attending a video presentation on clean code by Uncle Bob (Robert Martin), and we already had the pleasure of participating in another one in the series. This time the subject was Test-Driven Development (TDD).
After seeing the first video, I was already accustomed to the rather eccentric style of Uncle Bob and found his use of props and changing backgrounds entertaining rather than distracting. The new presentation had the form of a conversation between Uncle Bob and Mr. Spock, who is known for his purely logical worldview.
Uncle Bob explained how applying TDD improves the quality of source code, especially in large scale projects. He pointed out a common problem encountered by programmers working with complex systems, who are often afraid of making changes in existing (working) code, because it might cause unexpected problems. As a result, lower quality code is kept in the system.
Implementation of rigorous testing procedures mitigates these fears, since it allows the programmer who is making changes to the code to immediately run the tests and discover any problems. However, this only works when the programmer can fully trust the test suite. To make sure the tests are in fact trustworthy, the following three rules must be met:
- Any production code that is to be written must fix an existing, failing test.
- Every test must correspond to a specific missing feature or bug in the system, and must only check the minimal set of conditions sufficient for it to fail.
- It is forbidden to write more production code than is sufficient to make one failing test pass.
The advantages of the strict TDD approach are indisputable – in large projects, it allows programmers to work more effectively, it makes quality control much easier, and (as was already said) it eliminates the dangers of making changes in “old” code.
I won’t spoil the ending of the presentation and tell you whether Uncle Bob succeeded in convincing Mr. Spock of his perspective. He definitely did encourage me to try implementing TDD in a formal manner – I hope I will get a chance to do that in one of the projects that I’ll be working on in a near future.