[TIP] unitteset outcomes (pass/fail/xfail/error), humans and automation

Michael Foord fuzzyman at voidspace.org.uk
Wed Dec 16 07:15:14 PST 2009

On 15/12/2009 22:47, Robert Collins wrote:
> On Tue, 2009-12-15 at 16:24 -0500, Olemis Lang wrote:
>> But anyway , it is often possible to wrap the execution of those TFs
>> using customized instances of TestCase thereby recording the results
>> provided by those frameworks using TestResult&  Co.
>> PS: Does anybody knows about an exception to that «rule» ?
> Well yes, at the moment you cannot preserve the full resolution because
> the unittest module isn't very extensible.
> See for instance what nosetests's ErrorClassPlugin does / recommends:
> monkey patching the result object :- something totally incompatible if
> the result object is e.g. a gui result, or a remoting result.

I'm definitely in favour of making unittest more modular and extensible, 
but am worried about creating a situation where there are multiple 
incompatible extensions. It seems like this could be a problem with the 
proposed outcomes.

I'm interested in this discussion but have never had the need for custom 
outcomes, so don't feel I can add very much here.


> -Rob
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20091216/9d624c78/attachment.html>

More information about the testing-in-python mailing list