When is unit-testing bad? [was: Re: does lack of type...]

[Cameron Laird]

In article <bdunoh$1pms$1 at biggoron.nerim.net>,
Aurélien Géron <ageron at HOHOHOHOvideotron.ca> wrote:
>> In article <87of0pno5s.fsf at titan.staselog.com>,
>> Edvard Majakari  <edvard+web at majakari.net> wrote:
>> >
>> >I'm rather interested in (and fond of) unit testing as well as TDD, so I
>> >though to share my opinions. I once discussed TDD with my friend in here,
>> >and the common agreement seemed to be that TDD is not a silver bullet -
>> >often there are types of computational modules that are very hard to unit
>> >test, eg. think of graphical user interfaces or complex systems, where
>> >forking or threading is concerned.
>> .
>> .
>> .
>> While we're all being rational enough to look at bundles of
>> costs and benefits, this observation hints at a different
>> insight:  that it's possible to *design* for testability.
>>
>> Yes, GUIs and forking and threading are hard to test.  SO
>> DON'T DO THEM.  Or, as I prefer, adopt models of GUI and
>> concurrency development that lend themselves to testing.
>>
>> At this point, I should explain what I mean by that.  I
>> haven't yet figured out how to say it in less than a book;
>> therefore, all I can contribute for today are the slogans
>> above.
>>
>> If you're in a situation where unit-testing is bad, you're
>> probably in a bad situation.  Change your situation.
			.
			.
			.
>I think I sort of understand what you mean, Cameron, but IMHO it looks to me
>that you are trying to fit everything into one vision ("Everything looks
>like a nail when you have a hammer").
>
>There are things that are hard to unit test (I'm talking about automated
>unit tests here) and which you just can't do without in some projects.  For
>instance, the database!  I worked in a couple of projects with automatic
>unit tests for the DB related components, and having lived through it, I'm
>not sure that it was worth it at all!  Manual unit tests would have made
>much more sense.  The same goes for GUIs.  I'd be interested to know about
>projects where they automate unit tests for GUIs, but I suspect it would be
>just as cumbersome. And live without threads?  A lot of projects would be
>better off not using them, I agree with that, but some projects just can't
>do without them!  Web sites are also horrible to automatically unit test.
>In all those cases, I much prefer having a human being go out and do the
>unit tests manually.
>
>I guess my point is that though you may be right in some specific contexts,
>I don't think you can generalize.  That's IMHO of course.
>
>I may not have understood exactly what you meant, though.  You may want to
>send me a copy of your book?  ;-)
>
>Aurélien
>
>

David Bolen answers extremely well in his follow-up.

I think that, more than trying to hammer everything, I'm
saying that, if hammering works for you, then make a point
of building things with nails.

As everyone else, I'm trying to get at "the big picture".
Some organizations accept that
A.  TDD helps over-all business goals;
B.  The {GUI,concurrency,...} programming we
    do now is incompatible with TDD;
and conclude
C.  we must abandon TDD.
I propose instead
D.  Over-all business goals will be best
    served by a {GUI,concurrency,...} ap-
    proach that facilitates TDD.
-- 

Cameron Laird <Cameron at Lairds.com>
Business:  http://www.Phaseit.net
Personal:  http://phaseit.net/claird/home.html