[TIP] Result protocol / problems being solved

Michael Foord fuzzyman at voidspace.org.uk
Tue Apr 14 03:13:12 PDT 2009

Robert Collins wrote:
> On Tue, 2009-04-14 at 10:36 +0100, Michael Foord wrote:
>> Personally I think duration is the information you are likely to *want* 
>> and as stop can be derived from start and duration it makes sense to 
>> include those two. Not a big deal however (at Resolver Systems we use 
>> the duration to track tests that slow down and to analyse how to reduce 
>> overall test run time by looking at the long running tests).
> The reason I went with clock events in subunit was to allow calculating
> both 'time' and 'duration' and replaying them back to unittest at
> arbitrarily later times.
> I plan to keep proposing patches to make this sort of thing visible in
> unittest - but I don't want to have a large set of patches pending.
> Speaking of which...
> how is the startTestRun/stopTestRun patch - is it good to go?
> -Rob
It looks good to me. I'm a new committer so I still need the nod from 
another developer. Once I have pushed out fresh Mock and ConfigObj 
releases I'll return to unittest issues.

I'd like to just apply:

* startTestRun / stopTestRun
* a keyword argument to main (TestProgram) *not* to call sys.exit
* addCleanUp (with the fix to use while / pop instead of iterating 
through reversed and with a final resolution to the order debate)

I'd also like to review the 'removeTest' method patch. I like the 
functionality but am not sure about the patch.

After this I'd like to do a proper implementation of the discovery 
stuff. There is still one decision that needs to be made (not discussed 
so far) - should the top level directory be treated as a package? At the 
moment it is treated as a directory and all modules loaded separately. 
It should probably be checked for an __init__.py first and treated as a 
package if it exists.

I think the discovery (with the load_tests protocol) probably at least 
needs a mini-PEP writing, but I'm keen to avoid it becoming anything 
more of a bikeshed than absolutely necessary.

After that I would like to turn unittest and its tests into a package. 
I'm hoping to do all of this in time to get it into 2.7.

One other issue - at the moment the only way to use a custom TestResult 
is to to override the '_makeResult' method (off the top of my head - may 
not be quite the correct method name) of TestRunners. Would it make 
sense for the runTests method to take an optional result argument?

All the best,



More information about the testing-in-python mailing list