[TIP] unitteset outcomes (pass/fail/xfail/error), humans and automation
olemis at gmail.com
Mon Dec 14 09:15:18 PST 2009
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
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)
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
olemis changed the public information on the FLiOOPS project -
More information about the testing-in-python