I've been thinking quite a bit recently about Test Driven Development. Although I was first exposed to TDD in the early years of this century, I find it to be a weighty topic with much room for research and exploration. My chief interest is in the chasm that seems to exist between much of the "How To" literature and the real life challenges one faces when first learning to do TDD. Rob Sabourin and I talked about this one evening at the TISQA conference earlier this year, and he agrees that teaching others to do TDD well is not easy. He currently teaches a semester-long undergraduate class on the subject at McGill University where he serves as an adjunct professor.
Last week, I finished reading Test Driven Development By Example by Kent
Beck. This was at least my second time through the book, but some things I had forgotten and others had new meaning for me as my intervening experiences have given me different perspectives. There are times in the book, though, where I simply cannot see what the author sees that leads him to a particular implementation. The same was true recently as I re-read a blog post by Robert Martin where he describes test driving an algorithm for finding line breaks in text strings. Admittedly, both Mr. Beck and Mr. Martin have much more development experience than I, but in both cases the examples are relatively simple. This, to me, is one of the really interesting questions: do the insights so often necessary to generalize an implementation developed test-first come only from the best and brightest developers, or do they come only after many years of experience? Perhaps more importantly, is it possible to teach others in relatively short time scales to recognize the appropriate generalization, a process somewhat akin to bottling the insight for mass distribution.
With a current client, I'm helping to teach some newly hired developers the
basics of TDD. Through that work, I'm hoping to explore this issue and some
others that I feel lurk in the space between the trivial examples in basic primers and the real world of multi-object collaboration and external dependencies.
Last week, I finished reading Test Driven Development By Example by Kent
Beck. This was at least my second time through the book, but some things I had forgotten and others had new meaning for me as my intervening experiences have given me different perspectives. There are times in the book, though, where I simply cannot see what the author sees that leads him to a particular implementation. The same was true recently as I re-read a blog post by Robert Martin where he describes test driving an algorithm for finding line breaks in text strings. Admittedly, both Mr. Beck and Mr. Martin have much more development experience than I, but in both cases the examples are relatively simple. This, to me, is one of the really interesting questions: do the insights so often necessary to generalize an implementation developed test-first come only from the best and brightest developers, or do they come only after many years of experience? Perhaps more importantly, is it possible to teach others in relatively short time scales to recognize the appropriate generalization, a process somewhat akin to bottling the insight for mass distribution.
With a current client, I'm helping to teach some newly hired developers the
basics of TDD. Through that work, I'm hoping to explore this issue and some
others that I feel lurk in the space between the trivial examples in basic primers and the real world of multi-object collaboration and external dependencies.
RSS Feed