[TIP] Result protocol / pass-fail-error

Olemis Lang olemis at gmail.com
Tue Apr 14 06:11:05 PDT 2009


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

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

-- 
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