[TIP] testtools MultiTestResult

Jonathan Lange jml at mumak.net
Fri Oct 15 04:05:21 PDT 2010

On Fri, Oct 15, 2010 at 11:48 AM, Michael Foord
<michael at voidspace.org.uk> wrote:
>  On 15/10/2010 11:46, Jonathan Lange wrote:
>> On Fri, Oct 15, 2010 at 11:35 AM, Michael Foord
>> <michael at voidspace.org.uk>  wrote:
>>>  Hello testing in Python folk,
>>> Is the testtools MultiTestResult documented anywhere?
>> There's a class docstring. That's it.
>>> If it *is* may I suggest better documentation links on the PyPI and
>>> launchpad pages. If it isn't, grrrrr...
>> I'll try to make it better sometime soon –
>> https://bugs.edge.launchpad.net/testtools/+bug/661116. Ideally, I'd
>> love someone with the energy and wherewithal to maintain live API docs
>> from trunk&  latest release. The cron job I set up myself stopped
>> working weeks ago and has been on my "to do" list since.
>> FWIW, you just give the constructor a bunch of TestResults and then
>> MultiTR forwards the events it receives on to each of those
>> TestResults.
> Thanks.
> From looking at the code, as far as I can see testtools only provides
> TestResult objects and none that derive from _TextTestResult. Even the
> testtools TextTestResult doesn't derive from _TextTestResult.
> The unittest test runner is TextTestRunner. This *requires* a
> _TextTestResult because the test runner calls result.printErrors.
> (Questioning the wisdom of that is perfectly valid but long pre-dates my
> involvement....)
> It seems I can't use any of the testtools result objects with the standard
> unittest test runner. :-(

The main reasons none of the result objects support it are because
none of testtools' users (vast horde that they are) have asked for it.
and because it's a crummy interface. TextTestRunner ought to at some
point in the future call stopTestRun() instead of printErrors() and
let the result object drive its own reporting.

However, in the mean time, perhaps the best workaround is to write an
adapter. I'd definitely be open to accepting such a thing as a patch.
I'd even be open to writing it, but don't hold your breath, unless you
know some wicked breath-holding tricks I don't know about.


More information about the testing-in-python mailing list