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

[Peter Hansen]

"Aurélien Géron" wrote:
> 
> 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.

Databases are generally considered much easier to do unit tests for than
GUIs.  

GUIs are recognized as difficult, but there are already fairly well-known 
approaches for simplifying the process, depending on what you need/expect 
out of the testing.  For example, one should generally count on the GUI
framework to do what it does correctly and not try to test, for example,
that a call to a drawText() method actually puts pixels on the canvas.
Instead, one should be testing that a call to drawText() is made, and
contains the correct text and positioning.

Web sites are equivalently simple to test, if you aren't trying to test
the presentation itself.  For example, unit-testing web forms is pretty 
trivial.  In fact, in most cases for web stuff, you don't need to actually
run a server, but I believe here I'm getting into XP-specific terminology
where "unit" test refers to something quite different from "acceptance"
or "customer" test, which is where you would be running the actual server.

-Peter