[TIP] unittest2 and the future of nose

[Rob Guttman]

I'm at a decision point of investing in plugin development for either nose
or unittest2 (under Python 2.6).  What's the current status of unittest2
plugin extensibility?  Is it ready (even if in beta) or should I stick with
nose?


Thanks.

- Rob




*From:* testing-in-python-bounces at lists.idyll.org [mailto:
testing-in-python-bounces at lists.idyll.org] *On Behalf Of *Michael Foord
*Sent:* Thursday, March 04, 2010 5:30 PM
*To:* Kumar McMillan
*Cc:* TIP
*Subject:* Re: [TIP] unittest2 and the future of nose



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

[snip...]
> 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.

Michael


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


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



_______________________________________________
testing-in-python mailing list
testing-in-python at lists.idyll.org
http://lists.idyll.org/listinfo/testing-in-python
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100716/75d415a5/attachment.htm>