[prog] Unit testing

[Almut Behrens]

On Thu, Sep 02, 2004 at 03:32:05PM -1000, Jimen Ching wrote:
> On Thu, 2 Sep 2004, Almut Behrens wrote:
> >So, my short answer is:  document unit tests (almost) as well as any
> >other code, and try to avoid 'slapping things together'.
> 
> No offense, but in the real world, this is a luxury.  You know that right?
> 
> We all agree that unit testing can, and should, reduce your defects, and
> thus your development time.  But what ends up happening is not that you've
> introduced lots of bugs, but because the requirements keep changing, so
> you end up 'slapping things together' anyway.

No offense, either, but I'm not sure I understand what you're saying.
Is it (a) we shouldn't write unit tests at all, (b) we should write
them in a quick-n-dirty fashion, (c) we shouldn't document well what
the tests do, because that would take too much time,  or what else?
Not quite sure which part we're disagreeing on, if any... :)
In particular, I think your second paragraph below is roughly in line
with what I'm saying... Or am I misreading something?

Anyway, all that my above statement is trying to address is the OP's
questions on (a) how well to document unit tests, and (b) whether to
code them quickly or well.
IOW, I hold the opinion that, if you've decided, for whatever reason,
to employ unit tests and consider it feasible to write them, then it's
better to (a) document them properly, and (b) write high quality code,
applying similar standards like you would for other application code. 
My rationale being that poorly carried out testing is just a waste of
time, and in the worst case, it might even do more harm than good in
the long run.  I deliberately tried to avoid making any claims as to
the universal usefulness of unit tests or whatever, as this simply
wasn't the question.

You mentioned that requirements keep changing.  Well, I'm rather
familiar with moving targets, as I'm working on several projects
where the requirements virtually keep changing from day to day.  This
unfortunate circumstance has a variety of implications on how easily
you can find a good design, and keep it in sync with the moving target,
etc.  But this is a completely different issue, which regularly tends
to drift off into discussions on whether top-down, bottom-up design,
fast prototyping, etc. is the appropriate strategy to choose.
Quite frankly, I'm a little tired of this...

The question here, if any, could be, what conclusions we might draw
with respect to documenting the code.  And my conclusion would be to
document even more carefully under difficult outer circumstances.  I
believe that this a vital prerequisite to remain in control of what's
going on, and to prevent things from slowly turning into a total mess.

> 
> Also, unit testing isn't as easy as most people think it is.  In some
> cases, the unit test ends up more complex than the code it is testing.
> My experience suggests that one should try to make unit tests as clean as
> the code being tested.  But if you spend as much time debugging your test
> code as you do your deliverables, then it's time to throw one or the other
> away...

I think we can essentially agree on that :)

Almut