[TIP] unittest2, distribute, and doctests

[Barry Warsaw]

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
>> here:
>
>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.

Cool.

>> 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.

Sounds good.

>> 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 
>loaded.
>
>>    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.
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100611/e3b2c746/attachment.pgp>