[Top][All Lists]
[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