On Thu, Apr 24, 2008 at 02:03:53PM -0700, Timothy Selivanow wrote:
On Wed, 2008-04-23 at 22:38 +0300, Marius Gedminas wrote:
By the way, the usual way to run tests in the Zope-3-land is to use bin/test rather than setup.py test. It uses a slightly different test runner that uses a slightly different method of getting the test description and therefore hides this incompatibility. Which probably explains why nobody saw it before. On the other hand, compatibility with setup.py test is desirable, and this bug should be fixed.
I assume bin/test is part of zope.testing...
In a matter of speaking. As far as I can tell, the proper procedure is 1. Check out a zope-ish package from Subversion. 2. Run 'buildout bootstrap' if you've installed zc.buildout system-wide (easy_install zc.buildout) or run './bootstrap.py' if you haven't. This creates a script named 'bin/buildout'. 3. Run 'bin/buildout' to install all the necessary dependencies, build any C extension modules, and create any scripts in bin/. This step usually creates the 'bin/test' script. 4. Run 'bin/test' to run the full test-suite. To get a prettier, colourful result with progress indication, pass '-pvc' to the 'bin/test' script.
If so (I'm going to be installing it soon) how would I go about running the tests then? The ultimate goal of what I'm working on is packaging ZODB3, and I've been working my way through the dependencies.
Buildout automates all that for you. On the other hand, if you're working on packaging something for some distribution, maybe you don't want buildout to install the dependencies in a local subdirectory... Brian Sutherland and Ignas Mikalajūnas recently packaged nearly all of Zope 3.4 for Debian/Ubuntu. You may want to discuss packaging matters with them, I assume.
Do all of the zope-ish packages use zope.testing?
Yes.
I'd like to be able to include tests in %check, as I don't usually get to test the built packages right-a-way and this would at least show that it passes basic scrutiny.
Good idea.
Also, what was the rationale in making zope.testing instead of just using unittest. Does it extend unittest in a more zope-ish way (similarly for zope.buildout in regards to setuptool)? I'm just trying to understand the dynamics of the zope and python communities so I know areas to focus my attention.
unittest provides you with a way to write tests, and some automation for collecting all tests in a single Python file. This is not sufficient for Zope's packages that have hundreds of test modules. zope.testrunner builds on top of unittest and gives you automated test collection from multiple test modules, additional output formatting options (such as colorization), support for multiple test layers with expensive setup/teardown that you really want to do once and not once for every test, support for filtering and running just a subset of the tests from the command line, when you're making changes in a single module and want to run just the pertinent tests. I've probably left things out. It is entirely possible for Zope to move to a more-widely-used test runner such as nose, but currently no one seems to be interested in investigating whether nose has all the features that zope packages currently expect from their test runner.
https://bugs.launchpad.net/zope.testing/+bug/221151
The next step would be to write a unit test to reproduce this in zope.testing's test suite.
Thanks for submitting that bug. I'll look into writing a unit test based on the one that uses zope.testing, but while I understand the concepts of writing unit tests, I'm really just a n00b when it comes to all of this. I find that I learn the best by jumping straight in, feet first (not head first...broken legs are easier to deal with than a broken neck ;)
I kind-of wrote the test already, and then instead of comitting it and fixing the bug started flaming on this mailing list (sorry, everyone!). Marius Gedminas -- 1 + 1 = 3 -- from a Microsoft advertisement