[TIP] Implementation details of x-outcomes WAS: unitteset outcomes (pass/fail/xfail/error), humans and automation

Mark Sienkiewicz sienkiew at stsci.edu
Fri Dec 18 14:47:27 PST 2009

>>> I want to:
>>>  - be able to automate with them: if I add an outcome 'MissingFeature',
>>> I want to be able to add workflow and reports on that in my CI system or
>>> test repository.
>> while being language agnostic ? is that still a requirement ?
> I don't think language agnostic can really apply while we're talking
> about the python unittest API. I will want to figure out how to tunnel
> whatever design we come up with through subunit, in both directions -
> e.g. how to represent a custom outcome in junit in python - but thats my
> problem ;).

I don't think it is possible to tunnel custom outcomes through subunit 
as it exists today. The protocol is a line oriented name:value where 
each possible outcome has its own name. Looking at the protocol spec, it 
appears that a minimal subunit file looks something like:

fail: name3
success: name2
fail: name1
banana: tasty

This reports results for three tests (name1, name2, name3), but the line 
that says "banana" is not a test status for the test named "tasty". 
According to the protocol spec in the README, it is just "unexpected 
lines which are not interpreted by the parser". It looks like a new test 
status would need change to the protocol and a patch to each program 
that reads the protocol.

Of course, since subunit is still at version 0.0.4, maybe the protocol 
could be changed before it gets too entrenched. If you allow lines like:

status: word test_label DETAILS

where word is the name of a user-defined status or one of the existing 
statuses, it would be easy to pass custom statuses through the system. 
For example:

status: fail name3
status: success name2
status: fail name1
status: banana tasty
spinach: yukky

Here, I've added a test named "tasty" that yielded the result "banana", 
but the line about spinach is still unknown text to be ignored.

Of course, a processing system has to know what to do when it sees 
another status that it has never seen before, but that is implied by the 
idea that statuses might be user-defined.

Mark S.

More information about the testing-in-python mailing list