<div class="gE iv gt"></div>For
those who don't want to read the proto-pep, which outlines the *whole*
system and is a little bit long, I wrote up a *much* shorter intro to
the plugin system (including how to get the prototype) on my blog:<br><br>
<a href="http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186" target="_blank">http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186</a><br><font color="#888888"><br>Michael<br>
<br></font><div><span id="q_12a236e26030c9e6_2" class="h4">- Show quoted text -</span></div><br><br><div class="gmail_quote">On 29 July 2010 23:55, Michael Foord <span dir="ltr"><<a href="mailto:fuzzyman@voidspace.org.uk">fuzzyman@voidspace.org.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hello all,<br>
<br>
My apologies in advance if email mangles whitespace in the code examples. I can reformulate as a PEP if that is deemed useful and this document can be found online at:<br>
<br>
<a href="http://hg.python.org/unittest2/file/tip/description.txt" target="_blank">http://hg.python.org/unittest2/file/tip/description.txt</a><br>
<br>
(Please excuse errors and omissions - but do feel free to point them out.)<br>
<br>
This is a description, and request for feedback, of the unittest plugin system that I am currently prototyping in the plugins branch of unittest2_. My goal is to merge the plugin system back into unittest itself in Python 3.2.<br>
<br>
.. _unittest2: <a href="http://hg.python.org/unittest2" target="_blank">http://hg.python.org/unittest2</a><br>
<br>
As part of the prototype I have been implementing some example plugins (in unittest2/plugins/) so I can develop the mechanism against real rather than imagined use cases. Jason Pellerin, creator of nose, has been providing me with feedback and has been trying it out by porting some of the nose plugins to unittest [#]_. He comments on the system "it looks very flexible and clean". ;-)<br>
<br>
Example plugins available and included:<br>
<br>
* a pep8 and pyflakes checker<br>
* a debugger plugin that drops you into pdb on test fail / error<br>
* a doctest loader (looks for doctests in all text files in the project)<br>
* use a regex for matching files in test discovery instead of a glob<br>
* growl notifications on test run start and stop<br>
* filter individual *test methods* using a regex<br>
* load test functions from modules as well as TestCases<br>
* integration with the coverage module for coverage reporting<br>
<br>
In addition I intend to create a plugin that outputs junit compatible xml from a test run (for integration with tools like the hudson continuous integration server) and a test runner that runs tests in parallel using multiprocessing.<br>
<br>
Not all of these will be included in the merge to unittest. Which ones will is still an open question.<br>
<br>
I'd like feedback on the proposal, and hopefully approval to port it into unittest after discussion / amendment / completion. In particular I'd like feedback on the basic system, plus which events should be available and what information should be available in them. Note that the system is *not* complete in the prototype. Enough is implemented to get "the general idea" and to formalise the full system. It still needs extensive tests and the extra work in TestProgram makes it abundantly clear that refactoring there is well overdue...<br>
<br>
In the details below open questions and todos are noted. I *really* value feedback (but will ignore bikeshedding ;-)<br>
<br>
.. note::<br>
<br>
Throughout this document I refer to the prototype implementation using names like ``unittest2.events.hooks``. Should this proposal be accepted then the names will live in the unittest package instead of unittest2.<br>
<br>
The core classes for the event system live in the current implementation in the ``unittest2.events`` namespace.<br>
<br>
<br>
Abstract<br>
========<br>
<br>
unittest lacks a standard way of extending it to provide commonly requested functionality, other than subclassing and overriding (and reimplementing) parts of its behaviour. This document describes a plugin system already partially prototyped in unittest2.<br>
<br>
Aspects of the plugin system include:<br>
<br>
* an events mechanism where handlers can be registered and called during a test run<br>
* a Plugin class built over the top of this for easy creation of plugins<br>
* a configuration system for specifying which plugins should be loaded and for configuring individual plugins<br>
* command line integration<br>
* the specific set of events and the information / actions available to them<br>
<br>
As the plugin system essentially just adds event calls to key places it has few backwards compatibility issues. Unfortunately existing extensions that override the parts of unittest that call these events will not be compatible with plugins that use them. Framework authors who re-implement parts of unittest, for example custom test runners, may want to add calling these events in appropriate places.<br>
<br>
<br>
Rationale<br>
=========<br>
<br>
Why a plugin system for unittest?<br>
<br>
unittest is the standard library test framework for Python but in recent years has been eclipsed in functionality by frameworks like nose and py.test. Among the reasons for this is that these frameworks are easier to extend with plugins than unittest. unittest makes itself particularly difficult to extend by using subclassing as its basic extension mechanism. You subclass and override behaviour in its core classes like the loader, runner and result classes.<br>
<br>
This means that where you have more than one "extension" working in the same area it is very hard for them to work together. Whilst various extensions to unittest do exist (e.g. testtools, zope.testrunner etc) they don't tend to work well together. In contrast the plugin system makes creating extensions to unittest much simpler and less likely that extensions will clash with each other.<br>
<br>
nose itself exists as a large system built over the top of unittest. Extending unittest in this way was very painful for the creators of nose, and every release of Python breaks nose in some way due to changes in unittest. One of the goals of the extension mechanism is to allow nose2 to be a much thinner set of plugins over unittest(2) that is much simpler to maintain [#]_. The early indications are that the proposed system is a good fit for this goal.<br>
...<br></blockquote></div>-- <br><a href="http://www.voidspace.org.uk">http://www.voidspace.org.uk</a><br><br><br>