[TIP] The role of nose2 in relation to unittest2
jpellerin at gmail.com
Mon Sep 27 06:40:44 PDT 2010
I have nothing to add, really. :)
"The purpose of nose2 is to provide the functionality of nose using
unittest2 plugins" is exactly right.
One minor correction in case of confusion: nose2 does *not* provide
its own runner in the sense of a TestRunner subclass, just it's own
version of the unit2 script that is preconfigured by loading nose2's
plugin config file.
On Mon, Sep 27, 2010 at 6:50 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 26/09/2010 19:43, Arve Knudsen wrote:
> As I've been tinkering with nose2 and unittest2, and got to know the two
> better, the question has emerged as to exactly which role nose2 is meant to
> fulfill on top of unittest2.
> With the original unittest, nose's raison de vivre is pretty clear; seeing
> as unittest is rather an archaic/inflexible framework, there is an obvious
> need of a more modern, practical alternative. nose offers such an improved
> alternative. unittest2 on the other hand changes the game, as it is being
> designed with today's needs in mind, and is plugin-based (like nose). That
> unittest2 is a sound design is evidenced by the fact that nose2 implements
> its functionality as unittest2 plugins.
> Hello Arve,
> Well, presuming to speak for Jason here (partly)... My understanding, as
> author of the unittest2 plugins code, is as follows.
> The purpose of the plugins machinery being developed for unittest2 is to
> *allow* useful popular and frequently requested functionality for unittest
> (such as that provided by nose) to be provided in clean and simple ways. The
> plugins branch itself is not *intended* to replace nose - merely make it
> dramatically simpler to implement and maintain. That at least is the goal.
> The situation is confused by the fact that in order to ensure the plugins
> branch meets its goal I have implemented various 'example' plugins that have
> some overlap with the nose functionality. *However*, these plugins only
> cover a relatively small subset of the nose functionality.
> The purpose of nose2 is to provide the functionality of nose using unittest2
> plugins. This includes goals like, wherever possible, backwards
> compatibility with existing nose tests. (But not existing nose plugins as
> the mechanisms are too different.)
> Given that the meat of nose2 (excepting the runner) is already unittest2
> plugins, how does one define nose2's role? Why is there even a nose2 runner,
> can't one simply develop plugins to integrate with the unittest2 runner?
> More to the point, when now wanting to extend unittest2, why write plugins
> for nose2 rather than unittest2 itself?
> This is an interesting question. In a way nose2 becomes a set of unittest2
> plugins, including replacing and extending some of the 'default' plugins for
> unittest2. It is possible that some of the existing unittest2 example
> plugins may move into separate projects or into nose2.
> It could also easily become the case that nose2 provides useful libraries
> and functionality for writing unittest2 plugins. The nose2 runner exists to
> load the nose2 configuration and configure the nose2 plugins. (Otherwise the
> user would have to have the nose2 configuration in *their* config file as
> well as any additional plugins they wanted to configure.)
> At the *moment* the main reason to be interested in working on nose2 is
> because it is the future of nose - for both Python 2 and Python 3. If you
> are interested in the future of nose, or being able to write nose style
> tests with unittest for Python 3, then contributing to nose2 is an effective
> way of making that happen. Meanwhile the role of nose2 will grow and become
> All the best,
> Michael Foord
> Hope these questions make sense :)
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> 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