[TIP] unittest2, distribute, and doctests

[Michael Foord]

On 11/06/2010 23:05, Barry Warsaw wrote:
> On Jun 11, 2010, at 10:21 PM, Michael Foord wrote:
> [snip...]
>    
>>> 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?
>
>    

Yes. I intend for changes to go into Python 3.2 (and beyond) but I will 
keep unittest2 compatible with Python 2.4 - 2.7.

Once 3.2 is released I will be in a bit of a bind as further changes can 
go into 3.3 but unittest2 itself isn't yet compatible with Python 3. I 
guess I will have to either port unittest2 or maintain a separate 
version for Python 3 in parallel.

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

I'd be very in favour of the distutils2 / unittest2 combination (as I 
think it is the future) - but I guess it depends how mature distutils2 
is when quickly is in development.

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

Yes - but as mentioned above it will still be compatible with Python 
2.7. Absolutely no way to get further changes into Python 2.7 now though.

All the best,

Michael Foord


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.