[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