[TIP] unittest2 and the future of nose

[Michael Foord]

Wow - a really interesting email Jason, and one I'm very pleased to read 
- both for the future of nose and for the future of unittest.

(Note - huge discussion on #testing-python has just happened and I don't 
feel up to writing it all out. I will probably reply to a couple more of 
the emails in this thread and make the main points as I see them. Main 
take away - a clean and flexible extension mechanism for unittest / 2 is 
a very important factor.)

On 04/03/2010 20:51, jason pellerin wrote:
> nose has always been intended to be an extension of unittest -- one
> that opens unittest up, makes it easier to use, and easier to adapt to
> the needs of your crazy package or environment.
>
> Fact: unittest2 is coming:
> http://www.voidspace.org.uk/python/articles/unittest2.shtml
>
> ... indeed, it's already here (just not yet in stdlib).

Well - strictly speaking unittest2 is a backport of what *is* in the 
standard library in Python 2.7. unittest2 will never be in the standard 
library for 2.4-2.6 of course, and it is for users of those versions of 
Python that unittest2 exists.

> It does test
> discovery (though not by default),
Not sure what you mean by default? Test discovery is built in and 
available from the command line - you need to trigger it with a command 
line parameter however.

> can support test functions (though
> not by default),
unittest2 will almost certainly not support test functions by default ever.

> will eventually support a better form of
> parameterized tests than nose does,
Well, we have to catch up with nose first.
> and also will eventually support
> at least class and module-level fixtures.
>    
This is partly implemented already in unittest2 (in Hg - not in a 
released version).

> Second fact: I have very little time to work on nose anymore, and with
> offspring #2 due any day now, that's not going to change much for at
> least a few years.
>
> Third fact: setuptools is dying, distribute is going with it, and
> something called distutils2 is going to rise to take its place. This
> matters because a LOT of nose's internal complexity is there to
> support one thing: 'python setup.py test'. If that command goes away
> or changes substantially, nose will have to change with it.
>    

Input on the distutils2 "setup.py test" command will be appreciated. :-)

> Fourth fact: many high-level nose users want it to be released under a
> more liberal license than LGPL and won't become contributors
> until/unless that happens.
>
> I think this all adds up to starting a new project. Call it nose2.
> Call it @testinggoat. Whatever it's called, it should be based on
> extending unittest2, and designed to work with distutils2's test
> command. It should support as much of the current nose plugin api as
> is reasonable given the changes in unittest2. And it should be BSD or
> MIT licensed (or some reasonable equivalent) so more people feel
> comfortable contributing.
>
>    

I was intending to put some of the features that people currently 
appreciate in nose (like test functions and better support for using 
bare assert statements) into a module called simpletest. Maybe it makes 
more sense for that module to be called nose2 and for other people to do 
the work... :-)

All the best,

Michael
> And, crucially, it must not depend on me writing 90% of the code and
> reviewing all of it. To succeed, nose2 needs to be a community project
> -- not *my* project.
>
> Which means it's not going to happen unless enough of you folks are
> interested and have time to commit.
>
> What do you think?
>
> JP
>
> _______________________________________________
> 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.