[TIP] Result protocol / pass-fail-error

[Michael Foord]

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.

Michael

> Secondly by allowing to record failure objects (instead of strings
> like is done nowadays) inside TestResult.failures, TestResult.errors,
> and add TestResult.successful (or whatever name you prefer ;)
>
> For this I think the following things'd be necessary :
>
> - Allow to pass such objects in to TestCase's assertion methods (e.g.
> fail, failIf ...) in the place of the message string ...
> - Base classes (e.g. TestError, TestFailure, TestSuccesful) in order to
>   * Allow devs to create specialized test status classes in a
> consistent hierarchy (i.e. have isinstance support )
>   * Avoid supplying the an object to the wrong assertion method, for example,
>
> {{{
> #!python
>
> TestResult().addFailure(TestError('What is all this about?'))
> }}}
>
> - To be backward compatible, if a string is supplied in to the
> aforementionned methods then record an instance of the top-level class
> (e.g. TestFailure)
>
> Maybe further things would be needed
>
>   


-- 
http://www.ironpythoninaction.com/