[DUG] RE: Unit Testing

[Sean Cross]

At my previous job, we had extensive tests (about 2000) which was an
absolute lifesaver.  For testing database access stuff, we used a test
database with some common setup routines.

At my current job, there are no units tests yet, but there will be by
the time I am finished.

Sean

On 6/15/05, Leigh Wanstead <leighw at softtech.co.nz> wrote:
> 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.
> 
> 
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
> 


-- 
Regards

Sean
---------------------------------------
Sean Cross
mailto:sean at picsprint.com

Pics Print - The photo printing solution for Windows. http://www.picsprint.com

http://www.Intuitex.com - Multimedia software for Windows