[TIP] Result protocol / problems being solved

[Michael Foord]

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,

Michael

-- 
http://www.ironpythoninaction.com/