2013-10-24 00:00:00 -0700
Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place.
W. Edwards Deming
Last week, while in Vancouver, I attended a talk at the Autotrader offices on Test Driven Development (TDD). The Presenter was Rob Hale, a senior developer at AutoTrader.
AutoTRADER is a Canadian company based in Ontario. They have offices in most major Canadian cities, but the majority of their development staff is based in Burnaby, BC. They are currently branching out into mobile, which has doubled traffic through their site over the last year. During the talk, they stated that as of 2011-2012, over half of all used cars sold in Canada were sold through the AutoTrader system.
The talk was great into to TDD, with a high concentration of information. Better was the discussion afterward, which pointedly questioned the value of TDD, and the investment vs payoff. The presenter covered an introduction to TDD, an example solution coded with TDD. Integration testing was not covered.
Talk covered the following points:
TDD Workflow:
The cost of adopting TDD was described as high, with a large percentage of a project’s code existing as tests. However, the potential payoffs were also described as high. Tests provide a technical level of enforced documentation which describes exactly how a system is supposed to behave. Both the presenter and several Autotrader staff members described how they familiarized themselves with a new code base by first reading the testing specs. Michael Feather’s definition of Legacy Code as “code which doesn’t have unit tests” was repeated. The presenter was pointedly questioned on the time benefits/savings of TDD. Rob Hale commented that a scientifically valid answer was not available, as he had never worked on a project where the same functionality was developed twice: with and without TDD. However, he said a reasonable expectation was the elimination of “off by one” errors as return value size is a basic test which should always be implemented. He commented that in his experience, a simple “off by one” error can cost up to 3 man days, between detecting, reporting, and solving the error. He continued that the elimination of such common yet difficult to find errors usually justified TDD’s cost by themselves. Requirements for unit tests were discussed. The importance of mocking external dependencies, especially network requests, was described. As the testing spec grows, running thousands of unit tests must be extremely fast, or the benefits of TDD are eaten up by the time cost of running the suite. One interesting point was the effect that TDD has on coding. Gone are monolithic “master” functions with wide ranging functionality. These functions are too difficult to write tests for, require frequent refactoring, and too often fail when additional functionality is added. Instead, programmers quickly favor small “unit” functions of minimal size. These are simple to write tests for, and easier to maintain.
I think the value of TDD was well expressed. Building comprehensive unit tests has direct benefits when maintaining and upgrading software. TDD seems to present a methodology where writing reasonably comprehensive tests is actually a possible goal. The presenter recommended several books on the subject:The Art of Unit Testing and Pragmatic Unit Testing. Both are available in multiple computing languages.
