[TIP] unittest2 plugins

[Michael Foord]

On 24/07/2010 09:02, meme dough wrote:
> Hi,
>
> I see the email about unittest2 plugins.  I had a play with plugin mechanism.
>
>    

This is *very* much an experimental work in progress. When it is a bit 
more complete I will send an email to python-dev and this list 
describing the mechanism and solicit feedback on it.

For those who just want to play now it is in the "plugins" branch of the 
mercurial repo at:

     http://hg.python.org/unittest2

There are seven example plugins that I used as "use cases" for building 
out the extension api. They include a growl notifier, a pep8 - pyflakes 
checker, a pdb plugin that drops you into pdb on test fail, coverage 
integration, plus extensions to load doctests and load tests from test 
functions. They are examples only at the moment though...

> How will plugins be distributed?  Will there be an entry point like
> pytest / nose uses?  Will people have to manually activate plugins by
> editing unittest.cfg to add plugin so it gets loaded or will this be
> done automatically?
>    

The goal is to move this back into unittest itself, so it can't depend 
on setuptools entry points. unittest2 *could* use them, so long as it 
remains compatible with the unittest scheme.

The current mechanism is that plugins are specified (and configured) in 
a project specific config file or a user global config file. This is all 
"up for discussion" once the prototype is done. There is also an api for 
loading plugins, so frameworks can load whatever plugins they want.

Plugins are loaded by importing them from the name and then calling the 
"initialise" function if it exists. Because plugins are imported by name 
they can live anywhere on sys.path or in any namespace...

I am also about to create a "class based" extension mechanism (using the 
same hooks under the hood) to see if that is a nicer api.

> I settled on initialise creating plugin obj which always adds options
> and sets hooks it wants.  Then in start hook check options to decide
> if do something and in stop hook also check options to decide.  Should
> there be a hook between initialise and start that has access to
> options?
>
> :)
>    

Last night (before I saw this email) I checked in the "pluginsLoaded" 
hook point. This is called after all plugins have been loaded and 
command line arguments parsed - so plugins should use this if they want 
to do initialisation after command line arguments have been handled or 
potentially interact with other loaded plugins.

All the extension point names and how / when they are called and what 
attributes are available on the event objects they receive are all 
things to discuss.

All the best,

Michael Foord

> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>    


-- 
http://www.ironpythoninaction.com/