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

[Michael Foord]

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.

Michael

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


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


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