[TIP] testtools MultiTestResult

[Michael Foord]

  On 15/10/2010 12:05, Jonathan Lange wrote:
> 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.

That's a perfectly valid reason. :-) It just happens that 
MultiTestResult would have been ideal for me, but I'm using the standard 
TextTestRunner (actually via django) so can't use it. Oh well. :-)

> 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.

In unittest2 the TextTestRunner does work like this (only calling 
result.printErrors if given a result object without a stopTestRun 
method). This is not true in the Python 3.2 trunk. I can only imagine 
that this means there were some changes to unittest in Python 2.7 that 
weren't ported to Python 3. Dammit - I need to look into that.

Unfortunately the particular project I'm on (work) is using Python 2.6 
and vanilla unittest (via django), not unittest2. The good news is that 
unittest2 will be included in django 1.3. The bad news is that we're 
still using django 1.1.

All the best,

Michael

> 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.
>
> jml
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python


-- 

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.