gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUe-dev] [RFC] PyUnit Framework for GNU Enterprise


From: Jason Cater
Subject: Re: [GNUe-dev] [RFC] PyUnit Framework for GNU Enterprise
Date: Sun, 7 Sep 2003 19:41:50 -0500

James and I have long wanted a unit-testing framework for GNUe.  We both
have looked at PyUnit, but aside from some very basic stuff, we couldn't
figure out how we'd get a lot of GNUe's parts tested in a non-interactive
environment.

I'd like to see us try, though. I agree with Reinhard that each module
should have its own.  I'd imagine we'd add test/ directories to each
module. 

-- Jason 


On Sun, 07 Sep 2003 23:00:48 +0200
Jan Ischebeck <address@hidden> wrote:

> Dear Co-Developers,
> 
> GNUe still lacks a testing framework. 
> 
> After starting up gnue designer 20-30 times for checking if the
> appserver dbdriver is working correctly (adding schema introspection), 
> I couldn't stand it any longer and thought again that it would be great
> to have a good testing environment for the gnue software suite.
> 
> Short before releases some more testcases would be useful. Something,
> that would have been needed especially after that disastrous 4.x
> release. (I think it was a 4.x something, but I'm not sure.)
> 
> Now pre-release testing is better, but f.e. in 0.5.1 there are still
> some bugs (like some dbdrivers don't return the right record count)
> which wouldn't be there if all or many database driver would and could
> be tested a) thoroughly and b) in a short amount of time.
> 
> I know adding a testing framework needs work too, work that could be
> used to further develop other parts of gnue, but I think that it is
> necessary that we can test the most important parts of gnue -- that
> means gnue-common -- thoroughly. 
> 
> On this background I read some introduction about PyUnit and created one
> basic test class, which loads records from a database and checks both
> record count and the correctness of the data. 
> 
> With two other scripts it is possible to startup the tests in text and
> in graphics mode. (gcvs run_tests.py, gcvs run_test_gui.py)
> 
> The big plus of PyUnit is that its quite easy to use and to extend. So
> its quite easy to just add some classes and add new testcases. F.e. it
> is IMHO very important to check the type of values returned from the
> database. The pypgsql driver f.e. returns some PgInt types, which should
> be converted to some standard datatype like Int, Long or a Number type.
> This is something difficult to check by just using forms, but easy to
> check with a PyUnit test.
> 
> I don't think that everyone instantly being converts to a extreme
> programming freak, but I would be happy if the next or over-next major
> release could be tested thoroughly.
> 
> For now I put the code at http://ash.gnuenterprise.org/~jan/unittest/ ,
> because I'm not sure weither to put it below gnue-common or to create a
> separate cvs repository like gnue-unittests.
> 
> Please comment.
> 
> Jan
> 
> -- 
> Jan Ischebeck <address@hidden>
> 
> 
> 
> _______________________________________________
> Gnue-dev mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnue-dev
> 


-- 
Jason Cater
GNU Enterprise




reply via email to

[Prev in Thread] Current Thread [Next in Thread]