[TIP] The role of nose2 in relation to unittest2

[Michael Foord]

  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.

All the best,

Michael Foord


>
> Arve


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100929/135fc396/attachment-0001.html>