[TIP] The role of nose2 in relation to unittest2

[Arve Knudsen]

Hi Michael

On Mon, Sep 27, 2010 at 12:50 PM, Michael Foord
<fuzzyman at voidspace.org.uk>wrote:

>  On 26/09/2010 19:43, Arve Knudsen wrote:
>
> Hi
>
>  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.)
>

OK, I guess that maintaining compatibility with legacy nose tests is the
distinguishing point here. I wasn't aware of that particular design goal.

Personally I'd like to see the need for 3rdparty unittest(2) wrappers to go
away, for most uses. What I *think* unittest2 should provide is a (more or
less) state-of-the-art test runner, with a sensible set of basic
functionality, and the ability to be extended with extra functionality.

Thanks to you and Jason's information, I can now see that nose2 only
configures the unittest2 runner with nose2 plugins. Thus, nose2 is really a
unittest2 plugin suite with a specific purpose (reimplement nose).

How about a general way of installing unittest2 plugins so they are
automatically detected by the unit2 runner? This is how I'd like to be using
unittest2 I think; the runner gives me all the control I need (for example,
stop on first failure) and I can extend it with the domain-specific
functionality that I need (e.g., coverage analysis). Hudson is a good
analogue in this regard IMO; it's an excellent basic CI system, but
domain-specific functionality (e.g. Git integration) is implemented through
plugins. This design works superbly in practice, I might add :)

Cheers,
Arve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100928/57600406/attachment.html>