[TIP] The role of nose2 in relation to unittest2

[Arve Knudsen]

On Tue, Sep 28, 2010 at 3:59 PM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

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

Excellent!


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

Could you describe how detection/configuration of plugins would work? I'm
curious. Could it be viable to configure unittest2 to automatically detect
plugins, and also explicitly disable plugins (i.e., you want most plugins,
and only need to disable a few)? It just struck me as a sensible middle
ground.

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