In the last few months, I have been extremely busy working for a client(still working) developing a suite of applications. Quite naturally, TDD(Test Driven Development) is the standard choice. Writing unit-tests, seeing them fail, filling in code, seeing the green bar, mocking several objects, verifying the behaviors etc., have been such a fascinating experience.
As a welcome coincidence, I had to go to Hyderabad for a three day training on TDD. I had a group of fifteen experienced developers, trying hard to adapt to this style.
Developers working in pairs
We had lots of discussions, lots of questions about practical difficulties in following it in their company, managerial issues and so on. Like any other sessions on TDD, there were thoroughly-convinced, convinced-with-doubts-yet, skeptical and outrightly-rejected participants. As usual, the thoroughly-convinced were the ones in the lesser age group. It confirms my theory that developers need to be introduced to TDD(or anything good!!!) much earlier in their career.
To the doubtful souls, I always share Dr.Laurie William‘s research on TDD vs. Non-TDD that you can find here. Here’re some highlights on some of the results on making two sets of programmers develop using TDD and Non-TDD.
- The TDD developers took more time to develop the application, contrary to the research hypothesis.
- The possible reasons for TDD developers to take more time could include the fact that TDD developers developed test case along with code while non-TDD developers developed only the code.
- Further, the non-TDD developers failed to develop code according to the requirement specification resulting in faster implementation.
- The non-TDD developers were asked to write test cases after code development, however they failed to write any test cases.
- Only one pair wrote any worthwhile test cases.
- These test cases could not be evaluated due to lack of sufficient other data points.
The code of the professional programmers was evaluated using 20 black box test cases. The test cases validated the robustness of the code, such as error handling capabilities and degree to which requirement specifications were incorporated (An application that passes 15 or more test cases can be thought of as a robust application)
- 80% of the TDD pairs’ code passed majority of the test cases (passing 16 to 20 test cases)
- Only 50% of the non-TDD pairs managed to achieve the same
