TDD is BS?

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Jun 19 10:29:49 PDT 2013


On Wed, Jun 19, 2013 at 04:52:22PM +0200, bearophile wrote:
> irritate:
> 
> >My feelings about TDD changed when I saw that talk explaining TDD
> >in the context of double-entry bookkeeping in accounting
> 
> I think the usefulness of the TDD method is greatly different for
> different kinds of code to write.
> 
> This is another data point for the discussion:
> http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/
[...]

As someone else has pointed out, we need to distinguish between
unit-testing and TDD.

I love D's built-in unittests. They have singlehandedly improved the
quality of my code by leaps and bounds, just because they're so
convenient to use, and help catch careless mistakes early.

However, I am skeptical about TDD.  Ideally, what unittests *really*
should be used for, is to set expectations about what results a piece of
code should give, but *how* that code achieves said result is a major
question that's never adequately addressed by TDD.  Using the above
sudoku example (thanks, bearophile!), one can write a unittest that
verifies a sudoku solution, but that in itself says *nothing* about how
the code should go about deriving such a solution.  Producing "minimal
code" that satisfies the test simply gets you stuck in local minima
without ever getting any nearer an actual solution for the problem.

Before methodologies like TDD could even begin to work, one has to
*solve* the problem at hand first -- analyse the problem, explore its
structure, invent an algorithm, then one can verify the correctness of
one's implementation with unittests. You have to already have an idea
about how things are going to work, before TDD can help you.

Of course, for trivial everyday problems like sorting and manipulating
lists of stuff, moving numbers around, etc., TDD can certainly work well
-- because the underlying algorithms are so trivial that there's not
much need to actually do any algorithm design. In such cases, "minimal
code" is pretty close to "actual solution", so TDD converges on it
pretty quickly. For algorithmically hard problems, however, like solving
sudoku, or computing n-dimensional convex hulls, or writing a compiler
optimizer, TDD simply falls flat on its face because it doesn't even
begin to address fundamental issues of how one achieves the desired
results from the inputs in the first place.


T

-- 
Без труда не выловишь и рыбку из пруда. 


More information about the Digitalmars-d mailing list