[TIP] The role of nose2 in relation to unittest2

[Michael Foord]

  On 28/09/2010 14:17, Arve Knudsen wrote:
> Hi Michael
>
> On Mon, Sep 27, 2010 at 12:50 PM, Michael Foord 
> <fuzzyman at voidspace.org.uk <mailto: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.
>

Indeed, that is pretty much exactly the goal.

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

Well, yes... but nose functionality is not just to support legacy tests. 
The nose2 plugins (already) provide genuinely useful functionality as 
evidenced by the popularity of nose.

It should (unless it grows additional functionality which could happen) 
be possible to take any or all of the nose2 plugins and manually 
configure them for unittest2 without using the nose2 script. The nose2 
script is there as a convenience.

> 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 :)
>

When the extensions mechanism lands in distutils2 I will provide a tool 
that that does this - detects and configures unittest2 plugins for you.

The alternative is that installing a unittest2 plugin (or any package 
that also provides a unittest2 plugin) *automatically* activates it. 
This would slow down startup and mean that the only way of deactivating 
a buggy or unhelpful plugin is to uninstall the package that provides 
it. I'm reluctant to do this, but could provide an alternative runner 
(or command line switch perhaps) that does this.

All the best,

Michael Foord

> Cheers,
> Arve


-- 
http://www.voidspace.org.uk/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100928/71386a1b/attachment-0001.htm>