[TIP] unittest2 and the future of nose

Michael Foord fuzzyman at voidspace.org.uk
Thu Mar 4 14:29:43 PST 2010

On 04/03/2010 21:14, Kumar McMillan wrote:
> On Thu, Mar 4, 2010 at 2:51 PM, jason pellerin<jpellerin at gmail.com>  wrote:
>> Fact: unittest2 is coming:
>> http://www.voidspace.org.uk/python/articles/unittest2.shtml
>> ... indeed, it's already here (just not yet in stdlib). It does test
>> discovery (though not by default), can support test functions (though
>> not by default), will eventually support a better form of
>> parameterized tests than nose does, and also will eventually support
>> at least class and module-level fixtures.
> ...
>> Which means it's not going to happen unless enough of you folks are
>> interested and have time to commit.
>> What do you think?
> My gut reaction to all this is that unittest2 probably replaces most
> of Nose's functionality besides plugin support.  I say gut reaction
> because I would need to think about it harder and dig into unittest2
> deeper to be sure.

Right - unittest extensibility is the *really* big wart on unittest that 
I would like to address. That means some kind of plugin / extensibility 
mechanism that doesn't suck. It needs a lot of thinking about and quite 
a bit (but not too much) talking about.

> That said, one HUGE win for unittest2 would be if it could support
> Nose's plugin API.

I doubt unittest(2) will support *specifically* the Nose plugin API. We 
need to work out the best, and idiomatic, way of extending unittest. 
That does mean making sure that the major use cases of nose plugins are 

> The only part of Nose that is not implemented as a plugin that is not
> scheduled to be supported by unittest2 (yet) is config file support (I
> think?).  You can turn on any command line option in a config file
> which is really crucial for projects that depend on a lot of plugins:
> http://somethingaboutorange.com/mrl/projects/nose/0.11.1/usage.html

Yup. As soon as you want to support both test discovery (or even the 
running of individual test modules) plus an extensibility system (where 
individual modules are able to *depend* on particular extensions being 
used) then you also need to have *some* way of specifying what 
extensions are needed. Still an open issue, I don't know what the answer 
is, but I am aware it is an issue.


> Kumar
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python


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