[Zope-dev] Zope unit testing framework?

[Martijn Faassen]

Tres Seaver wrote:

> I got addicted to unit testing after reading John Lakos' excellent book, _Large
> Scale C++ Software Design_.  He emphasises not only unit tests, but a more
> elaborate strategy, "design for testability:"  not only does each module come
> with its own tests, but the system knows about dependencies between modules, and
> guarantees to test the depended-on modules before their dependents (so as to
> avoid spurious errors).

In fact I also read that book a while back, and it was the first to set me
on of good testing strategies. I don't think Lakos discusses tests that
automatically check the outcome though, as the UnitTest frameworks are 
doing. The advantage there is that you don't have to hand-verify the
test output, and that you can test often (so you'll see quickly when
something goes wrong).

Lakos's book is very insightful though. And then I discovered Python and 
since then most of my hacking in C++ has been on a hold..

> In the Zope world, I think this has to translate to somthing like:
> 
>  1. Each Python module should have a set of associated tests, which would by
>     preference live inside the "if __name__ == '__main__'" block at the bottom
>     of the module (an alternative would be to use Tim Peters' DocTest stuff,
>     which embeds the unit tests in docstrings).  One would then have a script,
>     like the one which compiles all the Python modules during installation,
>     to run these modules (perhaps using some fancy dependency analysis based
>     on the import statements?)

How would this work for things which use the Zope framework heavily, though?
It's perfectly possible to do associate somekind of unit testing with
Python modules, but the integration with the Zope framework seems to require
having to use the framework in order to do the tests. That could slow the
tests down a lot or make them too hard to perform, and the philosophy of
these tests is that they should run quickly and should be easy to run, so
you'll run them often.
 
>  2. For testing ZClasses, I am afraid that some kind of ZClient-based test
>     will be required.  Each test would:
> 
>     * Generate a suitably-unique folder name.
> 
>     * Construct a folder of that name off the root of the ZODB.

Or perhaps in some special 'scratchpad area'.

>     * Build all scaffolding objects inside the new folder.
> 
>     * Run the tests, capturing the results and comparing them against
>       expectations.
> 
>     * Finally, blow away the sandbox folder.
> 
> Perhaps, as you point out, some of the effort to disentangle the core Python
> model from the HTML view will make such testing easier to lay down in the Zope
> core itself.  Given a suitable framework, product developers could even allow
> third parties to contribute tests highlighting bugs they have found.
> > 
> > [1]
> > Martin Fowler, ed., Refactoring: Improving the Design of Existing Code,
> > Addison Wesley Longman, 1999
> 
> This is the best book I have read on the actual practice of "Extreme
> Programming" -- I recommend it highly.

Likewise. Like "Design Patterns", it talks about things about which you already
know but until then had no good way to talk about, and then adds some useful
things you *didn't* already know.

> > 
> > Kent Beck, Extreme Programming Explained, Addison Wesley Longman, 1999
> 
> This book is a somewhat higher-level view of XP, and an "apologetic" for it (in
> the old, technical sense).  Still quite useful to read, but not as much meat for
> the working programmer to digest.

I agree with your assessment here too.

> > 
> > [2]
> > http://www.python.org/workshops/2000-01/proceedings/posters/shprentz/shprentz.pdf
> > http://c2.com/cgi/wiki?PythonUnit
> 
> I have put up the code I currently use for unit testing Python modules at:
> 
>   http://www.zope.org/Members/tseaver/PyUnit

Cool!

Regards,

Martijn