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

[Olemis Lang]

On Mon, Dec 14, 2009 at 11:58 AM, holger krekel <holger at merlinux.eu> wrote:
> On Mon, Dec 14, 2009 at 10:59 -0500, Olemis Lang wrote:
>> On Mon, Dec 14, 2009 at 10:46 AM, holger krekel <holger at merlinux.eu> wrote:
>> >
>> [...]
>> >
>> >>  - I want to be able to control whether this outcome should be
>> >> considered ordinary or exceptional: should it cause a test suite to
>> >> error, or even to stop early?
>> >
>> > That's a matter of test-running to me, has almost nothing to do
>> > representing test outcomes.
>> >
>>
>> IMO it's a responsibility of the (test case | suite) to determine
>> whether something failed or not.
>
[...]
>
> Whether test
> running, outcome determination and categorization or reporting/interacting
> with a UI need to be done through the same "TestCase" class is an implementation
> detail.

Considering what I've read about xUnit (and the responsibility of each
class in the whole scenario) all this should be handled by TestRunner
+ TestResult , instead of Test(Case|Suite)

> FYI py.test just invokes separate hooks[*] which may or
> may not be coupled by a particular plugin.
>

Nonetheless it is also possible to implement something on top of those
to add whatever functionality is needed, and people are also free to
make different interpretations ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
olemis changed the public information on the FLiOOPS project  -
http://feedproxy.google.com/~r/flioops/~3/2oEVcZIoLdQ/flioops