Re: Re: rewrote tests in unittest/ to python unittests

Bram Moolenaar <[email protected]> schrieb am 05.08.03 13:18:48:
> 
> 
> Joerg Beyer wrote:
> 
> > on popular request (by a single guy) I rewrote the tests in
> > the a-a-p directory Exec/unittest to be regular python
> > unittests. One advantage is, that the tests wont stop (sys.exit())
> > if a single tests fail.
> > 
> > Another advantage might be, that other coders could write
> > unittests, since they know how the usual python unittests
> > work.
> 
> Thanks for making this, Joerg.  I'll try it out...
> Looks like you included all the existing tests.  Very good!  I'll dump
> the old tests and use your new module.

please verify that my version works for you. yes, I took all tests that
were in the unittest directory (and hopefully did not miss any :-)
> 
> One thing I noticed is that you "import *" from Process.  That is not a

well, this is what your unittest/process.py did, but you are right,
"from XXX import *" is in generall not a good idea.

> good idea, I'll change it to import assert_var_name only.  For the Error
> and Util modules I do allow "import *", but Guido already made a remark
> about this...
> 
> > I included the unittest.py (since Bram works with older
> > python releases that have it not includes - todays 
> > python releases have). It originally lives on:
> > pyunit.sourceforge.net
> 
> I'm using Python 2.2, which does include the module.  Since the module

oh, has changed recently? 

> is not required for normal use of Aap, and the module might change for
> future versions of Python, I think it's better not to include it.

that's OK. all I wanted is, to provide you a version that works
out of the tarball.

> We can produce a warning when the module is not available, with a hint
> where to obtain the module.  I suppose it's simple to install.  I'll add
yes, since the unittest.py is self contained you can unpack the pyunit
tarball and simply copy/move their unittest.py in a-a-p's unittest
directory (you could even provide a receipe to do that, right?)

> something for this, please check the next version of Aap.
> 
> > I attach a tarball, that should be unpacked in the Exec directory.
> > To run the tests just call:
> > joerg@home> python unittest/checks.py 
> 
> I'll add it to the test.aap recipe, so that "aap test" runs the tests.
> 
> Hmm, I noticed assert_var_name() was tested in the wrong way (already in
> the old unittests)!  The typelessness of Python didn't warn us for
> exchanging the two arguments...

I just converted the unittest - it seems a good idea to verfy that 
they (still) check, want you intended.
 
> > Later I will append unittest, that actually run receipes to test, if they
> > work. This tarball tests on a lower layer: python functions and classes,
> > but the technique is the same.
> 
> In what way would that be different from what is currently used to
> execute the tests in the "rectest" directory?

I thought that that was, what you initially wanted. To clarify this:
unittest are best in testing (smaller) units. 

The running of the tests in rectest is an integration test, that takes
the entire aap and you dont really need the unittest interface to
do this.

If you name a class that could be tested easliy (because it's
interaction with other object is small) then I will try to figure
out a unittest for it. Later, with a deeper understanding
of aap's internals it might be easier for me to write some
larger tests.

One thing that _should_ be unittest'ed is the aap-rule engine,
but right now, I dont understand it good enough. One could
provide a ruleset and trigger certain targets, expecting (or better:
asserting) the right action to be triggered.

    Joerg



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01