[DUG] RE: Unit Testing

Fri Jun 17 11:16:06 NZST 2005

Leigh,

I was reading back thru this thread as I initially missed it - it's of
interest to us as we don't do this but we would like to be.  Currently we
have over 60mb of delphi code without any unit tests - we are trying to
figure out where to start, maybe figuring on only writing tests for new code
and leave the existing code along.

Nahum Wild
Group Leader - Development
PayGlobal 

> -----Original Message-----
> From: delphi-bounces at ns3.123.co.nz 
> [mailto:delphi-bounces at ns3.123.co.nz] On Behalf Of Leigh Wanstead
> Sent: Wednesday, 15 June 2005 17:00 p.m.
> To: Sean Cross; NZ Borland Developers Group - Delphi List
> Subject: RE: [DUG] RE: Unit Testing
> 
> I have 323 unit tests covers 500kbytes delphi source code. 
> Unit test delphi code is 158k bytes. I have 1.3mbytes delphi 
> source code not covered by unit test. I am working on that. ;-)
> 
> Regards
> Leigh
> http://www.salenz.com
> 
> -----Original Message-----
> From: Sean Cross [mailto:sean.cross at gmail.com]
> Sent: Wednesday, 15 June 2005 4:51 p.m.
> To: leighw at softtech.co.nz; NZ Borland Developers Group - Delphi List
> Subject: Re: [DUG] RE: Unit Testing
> 
> 
> 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
> 
> 
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
> 