[TIP] Result protocol / problems being solved
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?
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