[TIP] unittest2 plugins
fuzzyman at voidspace.org.uk
Sat Jul 24 02:39:01 PDT 2010
On 24/07/2010 09:02, meme dough wrote:
> 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:
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
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,
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
More information about the testing-in-python