[TIP] The role of nose2 in relation to unittest2
arve.knudsen at gmail.com
Wed Sep 29 06:21:38 PDT 2010
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:
>> 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
> 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
> 2) A config management tool could be used to show all available plugins and
> activate / disable them (basically a configuration management tool).
> Option 1:
> zero configuration for the case where you want installed plugins to be
> still needs manual configuration where you want to disable available
> needs to query all installed packages every time the runner starts
> Option 2:
> no performance implications
> more 'explicit': after installation plugins must be explicitly
> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python