TDD is BS?

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Jun 21 13:55:20 PDT 2013


On Fri, Jun 21, 2013 at 12:11:51PM -0700, Walter Bright wrote:
> On 6/21/2013 3:04 AM, Jacob Carlborg wrote:
> >But I do some researcher about TDD and similar techniques, use my
> >common sense, pick some pieces from here and there and use what I
> >think works.
> 
> I've been around long enough to have seen an endless parade of magic
> new techniques du jour, most of which purport to remove the
> necessity of thought about your programming problem.
> 
> In the end they wind up contributing one or two pieces to the
> collective wisdom, and fade away in the rearview mirror.

+1, words of wisdom.

>From "high-level language" to "structured programming" to "OO" to
"aspect-oriented programming" to X-oriented Y-driven whatever that is
the next bandwagon, it's all the same story repeated over and over.
It's supposed to be the panacea that will make you able to ship a
product just by pressing a single magic button, solve all your
programming problems, and cure world hunger. Then you actually get into
it, and discover that you still have to (gasp!) use your brain to get
your program working. And life goes on as before.


> But there is one technique that stands head and shoulders above the
> others in improving code quality, sometimes dramatically so. That's
> unit testing coupled with a coverage analyzer.
> 
> I can't even count the number of times I thought "this is so simple,
> I couldn't have gotten it wrong, I doan need no steeenkin unit
> tests." But I write a couple anyway, and you can guess the rest.

Yeah, I used to be firmly in the camp of "this code is so trivial, so
*blatantly* correct, that it constitutes its own proof of correctness."
Until D came along and shamed me into writing unittests for said
"trivial" code, and suddenly I found myself sinking in the flood of
bugs, failing corner cases, and (gasp!) typos, that I hadn't imagined
were there all along.


> Whether you write the unit tests before, during, or after the module
> is written is irrelevant.

Yeah, sometimes I start with one or two tests before, usually a whole
bunch in the middle, and a couple after (followed by a lot more later
when bugs are inevitably found and fixed). The best part about D's
built-in unittests (and I keep harping on about this) is that they're so
dang convenient you'd be foolish for not writing them. They can be
integrated into the very process of coding -- which has singlehandedly
improved the quality of my code by leaps and bounds.


T

-- 
IBM = I'll Buy Microsoft!


More information about the Digitalmars-d mailing list