[TIP] The role of nose2 in relation to unittest2

[Arve Knudsen]

On Wed, Sep 29, 2010 at 2:05 PM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

>  On 28/09/2010 20:24, Arve Knudsen wrote:
>
> [snip...]
>
>>   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.
>
>
> distutils2 allows installed packages to include metadata and provides an
> API for querying that metadata. One of the proposed bits of metadata is to
> be about extensions.
>
> unittest2 will be able to call an api that queries all packages installed
> by distutils2 and gets back a list of all available plugins.
>
> So there are basically two possible approaches:
>
> 1) On startup the unittest2 test runner could call this api, discover all
> available plugins and activate all of them except for explicitly disabled
> ones.
>
> 2) A config management tool could be used to show all available plugins and
> activate / disable them (basically a configuration management tool).
>
> Option 1:
>
> Pros:
>     zero configuration for the case where you want installed plugins to be
> activated
> Cons:
>     still needs manual configuration where you want to disable available
> plugins
>     needs to query all installed packages every time the runner starts
>
> Option 2:
>
> Pros:
>     no performance implications
>     more 'explicit': after installation plugins must be explicitly
> activated
> Cons:
>     installed plugins must be explicitly activated to be used
>
> Of course *both* are possible - with either two different test runner
> scripts or a command line switch to choose between them.
>
> Whichever of these three options (1, 2 or both) is implemented, alternative
> tools (like a GUI) could still be implemented to manage the configuration.
>

Sounds to me like we're on the same page, Michael!

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