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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] > Sent: Wednesday, 15 June 2005 4:51 p.m. > To: [EMAIL PROTECTED]; 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > Sent: Wednesday, 15 June 2005 4:28 p.m. > > To: [EMAIL PROTECTED]; 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 > > [email protected] > > http://ns3.123.co.nz/mailman/listinfo/delphi > > > > > -- > Regards > > Sean > --------------------------------------- > Sean Cross > mailto:[EMAIL PROTECTED] > > Pics Print - The photo printing solution for Windows. > http://www.picsprint.com > > http://www.Intuitex.com - Multimedia software for Windows > > > _______________________________________________ > Delphi mailing list > [email protected] > http://ns3.123.co.nz/mailman/listinfo/delphi > _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
