[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