[TIP] Result protocol / pass-fail-error

Jesse Noller jnoller at gmail.com
Tue Apr 14 06:31:58 PDT 2009


On Tue, Apr 14, 2009 at 9:11 AM, Olemis Lang <olemis at gmail.com> 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 :

Backwards compatible with what?

> - ERROR
> - FAIL
>  * KILLED
>  * TIMEOUT
>  * UNKNOWN
> - PASS
>  * SKIP
>  * WARNING
>  * DISABLED
>  * MISSING
>  * INCONCLUSIVE

We only define the high level entities, the rest is splitting hairs on
a per-deployment basis.

As for the rest of what you're talking about:

I am not talking about redefining unittest.TestCase statuses.
I am not talking about redefining unittest.TestCase statuses.
I am not talking about redefining unittest.TestCase statuses.

If unittest wanted to have "i_haz_a_pony" as a status, then it would
emit that. The collector/executor would then report that.

It's up to the *consumer* to take action on a default status, versus a
custom one. The executor need only report that.

jesse



More information about the testing-in-python mailing list