[TIP] Result protocol / pass-fail-error

Olemis Lang olemis at gmail.com
Tue Apr 14 07:36:32 PDT 2009


On Tue, Apr 14, 2009 at 8:24 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Olemis Lang wrote:
>>
>> On Mon, Apr 13, 2009 at 3:25 PM, Doug Philips <dgou at mac.com> wrote:
>>
>>>
>>> I'd like to see a --simple-- way to extend these status codes. Maybe:
>>> Anything not completely UPPERCASE is implementation defined.
>>>
>>
>> The idea I have is to be consistent with the current test status
>> (ERROR, FAILURE, SUCCESS | PASS | NOT EXPLICITLY FAILED- ) in order to
>> be backward compatible. However allow to specialize the status codes
>> in an OO manner. Firstly by establishing a hierarchy like the
>> following :
>>
>> - ERROR
>> - FAIL
>>  * KILLED
>>  * TIMEOUT
>>  * UNKNOWN
>> - PASS
>>  * SKIP
>>  * WARNING
>>  * DISABLED
>>  * MISSING
>>  * INCONCLUSIVE
>>
>
> More like:
>
> - ERROR
> * KILLED
> * TIMEOUT
> * UNKNOWN
> * MISSING
> * INCONCLUSIVE
> - FAIL
> - PASS
> * SKIP
> * WARNING
> * DISABLED
>
> I'm not sure if a heirarchy is right anyway. They all seem like separate
> statuses and the reporting tool can group them if it wants.
>

Well I mentionned the reasons why I said so in the previous message.

I'll mention my ideas:

- fail | pass | error is a model widely adopted, and is the one we
have today ;).
- Provided that IMHO error should signal an error in the test code
itself (not a wrong behavior in the SUT) then I put the statuses
inside FAILURE since:
  * KILLED : If KILLED means that the testing infrastructure took
action then it doesnt mean that my code is not well-written but that
the test was not completed successfully
  * TIMEOUT : same as above
  * UNKNOWN : same as above
  * INCONCLUSIVE : according to the original description the test «did
not FAIL» (so its not a failure), the test code is not wrong either
(so its not an error) but did not produce statistically valid PASS
either (so its not exactly a clean PASS). Therefore that's why I
considered it a PASS.

If you consider that putting'em inside ERROR is better, well that's
fine for me ... and if you think its not a valid suggestion it's ok
anyway ;)

-- 
Regards,

Olemis.

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

Featured article:



More information about the testing-in-python mailing list