[TIP] unittest2, distribute, and doctests

Michael Foord fuzzyman at voidspace.org.uk
Mon Jun 14 12:17:12 PDT 2010


On 14/06/2010 19:50, Jonathan Lange wrote:
> On Mon, Jun 14, 2010 at 2:18 AM, Robert Collins
> <robertc at robertcollins.net>  wrote:
>    
>> Related to regexp filters, I really want two things in core; I have
>> implementations in various places I can propose when trunk unfreezes.
>>
>> Firstly, getting the filter (whatever it is) from a file, with one
>> entry to the filter per line, entries are OR'd together.
>>
>> Secondly, an exact match filter - where the filter specifies the test
>> *id* (and applies *after* load_tests, because that permits both
>> parameterisation that multiplies tests and changes ids, and doctests
>> where the ids are not directly importable python names).
>>
>>      
> They sound pretty easy to do. Michael, would you accept patches along
> these lines?
>    

Well, yes... However... they can't go into Python 2.7. They would all be 
*trivially* easy if unittest had a good extension API, and as there are 
several feature requests in this area it sounds like module filtering 
and test loading should be the first extension points implemented and 
these will make good example "extensions" that can be shipped with 
unittest(2).

As the extension API grows I'd like to see what functionality it makes 
sense to take *out* of the core unittest and move into extensions. This 
should make unittest itself easier to understand and make it easier to 
override default behaviour.

In other words I'd be much more interested in *first* discussing what 
the extension API should look like and maybe start implementing it. This 
should probably be done in a branch.

I'll write-up a new email on the extensibility system I imagine (heavily 
inspired by py.test and discussions with Holger) for comments. It will 
be based on registering functions for extension points and with both 
per-project and per-user config files to enable / configure individual 
extensions (plus allowing extensions to register command line options to 
enable / disable them).

Hopefully I can show an example implementation for a couple of extension 
points and some example uses - perhaps these use-cases. This shouldn't 
take *too* long, so hopefully I can do it soon - even if the code 
doesn't land on trunk for a while. Once the basic details are agreed the 
difficult task is exactly where the extension points go and what 
arguments they take, what they should return etc... I don't think that 
there is any way round deciding these on a case-by-case basis. Obviously 
it is better for the system to "mature" a bit before going into unittest 
(Python 3.3 perhaps? it would be nice to have it in 3.2) as backwards 
compatibility rules make it much harder to change once it is in Python.
All the best,

Michael

> jml
>    


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





More information about the testing-in-python mailing list