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

[Jan Ischebeck]

Am Mo, 2003-09-08 um 02.41 schrieb Jason Cater:
> 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 would try to test the gnue-common core functionality first, because it
doesn't need that interactive stuff. At a later state we probably have
to write our own GUI testing tool, as I don't know if python already has
something like that, and the only good GUI testing tools I've heard of
are commercial.

> 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 

I put the stuff I've written in a unittest directory. I would prefer to
name it unittest to distinguish between test="test every single part of
the app" and test="try me out". If you think that the name 'unittest' is
misleading, to long or not necessary please feel free to rename it.

Jan

> 
> 
> 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
> > 
-- 
Jan Ischebeck <address@hidden>