[TIP] Result protocol / data content

Doug Philips dgou at mac.com
Mon Apr 13 18:16:21 PDT 2009


On or about Monday, April 13, 2009, at 03:12PM, Mark Sienkiewicz  
indited:
> Jesse Noller wrote:
> I'm with you here.  It is _far_ more important to define the content  
> of
> each record than to choose a wire format.

Yay! Progress!

It seems we have two levels of data here:
-- Data having to do with an individual test.
-- Data having to do with the aggregate of some number of individual  
tests.

Either we use the wire protocol to handle the nesting/aggregation of  
individual tests, or make it explicit data in the aggregate's data.

What, in my projection of the Tutisian-sense/defintion-of-simple, is  
the simplest thing we need:
Test identification and test result.
    Foo: PASS
    Bar: FAIL

--everything-- else should be optional, not included if not needed.

On thing I like about Pandokia's tactic is the concept of "if this  
specific test doesn't indicate a value for 'x', use this one". OTOH,  
that could just as well be provided, per test, by the test-running- 
infrastructure, so I'm not sure it is needed. Most of the additional  
data I'm OK with, but I don't see the need for all this nesting  
brouhaha, seems over engineered. I can see one level of nesting for  
the attributes associated with each test. Additional nesting within  
should be implementation-extension. Really, if I want stdout, stderr,  
trace-foo, whatever, do I really need a separate container for it?

Consumers (after the wire-protocol-reader is done) should ignore  
anything they don't understand, but pass it through if they are also  
generators.

Back to the spice mines,
	-Doug




More information about the testing-in-python mailing list