[TIP] unittest2, distribute, and doctests
barry at python.org
Fri Jun 11 15:05:55 PDT 2010
On Jun 11, 2010, at 10:21 PM, Michael Foord wrote:
>> First problem, unlike the "standard" distribute 'test' command, you have to
>> build the package first. Otherwise you get a traceback. Full traceback is
>Ok, I can look into this. distribute / setuptools must be doing
>something odd with the path - when the collector imports the enum tests
>it is picking them up from the wrong location.
>> Second caveat: It would be nice if distribute and unit2 could agree on an
>> API for locating "extra" tests. For example, in flufl.enum, I have a
>> function that turns doctests into DocFileSuites with appropriate flags,
>> setups, etc.
>Well... unittest2 is a backport of unittest in Python 2.7 which has just
>got to release candidate and isn't about to change dramatically.
Right, I keep forgetting that. :) Do you plan on continuing to develop
unittest2 after 2.7 is released, adding enhancements and such, with backports
to Python 2.7?
>On top of that the load_tests protocol is more flexible than
>'additional_tests' and so is *better*. setuptools isn't about to change
>either, so I don't know what we can do here?
>The good news is that distutils2 will use unittest / unittest2 and so
>load_tests alone will be sufficient. Of course if you're actually
>*using* unittest2 then load_tests is still sufficient, and if you're not
>using unittest2 then you don't need it.
I need to look at distutils2. What I'm really trying to figure out is which
libraries I want to promote for use in 'quickly python', and how to do it. So
distutils2/unittest2 might be that path. (I'm still working on getting Python
2.7 into the next version of Ubuntu.)
>Right. So I'm convinced that sometimes regular expressions are sometimes
>better. I don't think that we can change the default and I'm not sure
>that proliferating command line options is ideal either. I would like a
>way of filtering tests from the command line though.
>Filtering files like this - including loading text files and turning
>them into doctests - should be straightforward with the plugin mechanism
>I have 'in mind'. It could initially be developed as a plugin, but a
>standard set of useful plugins could ship with unittest / unittest2.
>These could be enabled globally with a user config file or on a per
>project basis. They could even (conceivably) add new command line
>options (both nose and py.test have systems similar to this).
That sounds like a good plan. After Python 2.7 is released though right?
>> Of all the test runners out there, I really do like Zope's command line
>> interface the best. Just something to keep in mind I guess.
>I'm not at all familiar with it, but would certainly appreciate input on
>any improvements to the unittest(2) command line interface. Specific
>feature requests (or even just one explaining which features from the
>zope test runner you particularly like) would be helpful - either on the
>Python or the unittest2 bug tracker. I'll try and have a look at it
>before I make any further changes.
>> So the problem is probably related to not calling load_tests() when the
>> pattern doesn't match a discovered file name.
>Right - load_tests is only called for modules (files) that are actually
>> The bummer about that is that I
>> was going to try to use load_tests()'s pattern argument to filter the doctests
>> that got run, since it makes sense that unit2 doesn't (yet<wink>) know about
>> doctest file names.
>The pattern currently filters files, not tests. I'd like to be able to
>filter tests as well. Loading tests from text files will have to be the
>work of an extension.
That makes sense! Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the testing-in-python