[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.
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>
More information about the testing-in-python
mailing list