TDD is BS?

[Nick Sabalausky]

On Wed, 19 Jun 2013 13:01:02 +0200
"Szymon Gatner" <noemail at gmail.com> 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.