[TIP] unittest2 and the future of nose
jpellerin at gmail.com
Thu Mar 4 12:51:30 PST 2010
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:
... 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.
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.
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
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?
More information about the testing-in-python