On Wed, 19 Jun 2013 13:01:02 +0200 "Szymon Gatner" <[email protected]> wrote:
> This is not strictly D related but I am very curious about D's > community opinion on the points made by non other than Jim > Coplien here: > > http://www.tele-task.de/archive/video/flash/16130/ > > D is the only language (that I am aware of) that has first class > unit testing support. What do you think? Do we really just > "mentally masturbate"? > > Article about the myths of TDD referenced in the talk: > > http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1027&context=csse_fac The main problem I have with TDD is that it's simply the latest form of ideology-oriented-development. It follows the same pattern as OO in the late 90's, and the popularity of Haskell and such a few years later: 1. Take a good idea (objects, functional programming, unittests, short iterative cycles, etc, whatever). 2. Decide "If using some of this is good, then forcing everything into this mold must be fantastic!" 3. Some die-hards sip the kool-aid, but the rest just adapt the good parts pragmatically, stripped of the ideological baggage. 4. The die-hards run into problems eventually forcing the more level-headed among them to admit "yea, turns out there are limitations to this alleged silver bullet after all". Meanwhile everyone else continues to just enjoy the benefits because they were sensible enough to only apply the idea in situations where it actually fit in the first place. Unittests are great. Minimizing the amount of code changes in each iteration of your code-compile-test cycle is great. But there are *always* other concerns, and those concerns must always be balanced. For example: - As people have said, some things aren't well-suited to automated testing. - Sometimes you run into something that just *is* a big all-at-once change where splitting it into smaller tasks, while being ideal, would be impractical. - Writing a unittest first forces the API to be designed before the implementation is written. But implementation is necessary to flush out unexpected design requirements (If you think you can always come up with an appropriate design and interface before implementing, then you're just plain wrong). Sometimes the appropriate design and API is obvious. Sometimes it isn't. When it isn't, then TDD skirts dangerously close to some of the problems of "Waterfall Model". Sure, TDD advocates refactoring-as-needed, but I can do that with or without TDD.
