[DUG] RE: Unit Testing

[Leigh Wanstead]

My experience is write unit testing at least test cover one case of each
legal and illegal parameters of a procedure. This way I am sure that invlid
parameter won't pass through.

If user report bugs, then check to see if existing unit test case cover the
bug or not. Usually the answer is no, so write a unit test case to cover it.

Regards
Leigh
http://www.salenz.com

-----Original Message-----
From: Allan, Samuel [mailto:S.A.Allan at massey.ac.nz]
Sent: Wednesday, 15 June 2005 4:28 p.m.
To: leighw at softtech.co.nz; NZ Borland Developers Group - Delphi List
Subject: Unit Testing


I would be really interested in hearing other people's experience with
unit testing, because it is something that I try to do, and would like
to do better. I don't exactly write them first every time XP style, but
I do write them. I also don't unit test everything. I am using DUnit,
because it is free.

For my current project I have found them very useful. I have used them
for the engine behind my software. So non-visual and mostly non-DB.
Because requirements have changed a little, and bits and pieces have
been re-written to match, it has been good to be able to know that
nothing else is broken. I think that the piece of mind has been worth
the time invested.

I have also found that writing DUnit tests can be as quick (or quicker)
as testing some things by hand. I started out writing a test app for
this project, and went to DUnit when I realised that I was wanting to
run the same tests over and over, and writing a DUnit test was just as
time consuming (or less so) as setting up my manual test for just the
one run.

However, I have found that I often have to re-write the tests when I
change the code. And there is no test for the test, if you follow. I
have had one bug where a test did not setup the fixture right, so passed
when it should have failed.

Also, often the code in the tests is more long-winded than the
application code. But less complicated. Perhaps this is my poor test
writing. And my tests are often more than just one Check(), but given
the amount of setup code... In general, I find most of my test code is
setting up fixtures.

I do not write unit tests for DB accessing code or for GUI stuff. We do
not have a framework to fake DB access, or a suitable database
environment for it. I don't think I can justify the time to write setup
and reset database stuff into my tests. I tried once or twice, but did
not have the tools so it seemed not worth the time. So I test that
manually. However, I have so far managed to work around not being able
to test DB accessing code.

I don't test the obvious. If it is gonna work or not, and it'll be
blatantly obvious which, then I don't spend the time. For example, I see
no benefit in testing a method which goes "return False;". Maybe I
should.

Because I don't test everything, I still have to check stuff manually,
and I am not certain that the software is good even when it is all
green. But all in all, I think it has been worthwhile.