[TIP] unittest2, distribute, and doctests
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
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,
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