jnoller at gmail.com
Fri Apr 10 19:28:20 PDT 2009
>> JSON is in python2.6
> Still using 2.4.4 - corp world doesn't upgrade unless there is sufficient
> reward to overcome the pain. Maybe in aggregate a new test reporting backend
> processing system will be the straw that breaks the status-quo-camels
But I'm not building it for you :)
>> Also, I've already built things using "simple" formats - plain
>> INI-style formats, etc. I found they didn't scale and were not
>> extensible enough for me long term.
> Looking at json, it seems rather rigid in a distributed environment where
> tests could go away half way through, so the json could be interrupted at
> all kinds of 'inconvenient' places.
No. You don't handle results as a stream. You run, you parse what you
need out, and send a well formed message back, containing logs,
charts, debug information (logs from the product), etc. You don't let
tests directly write to the object you're going to send back to the
Doing that means that yes, you can have tests crap on your message
back to the mothership - no matter the format, that will always cause
>>> Quite so. What you are talking about is remote job management.
>>> That the jobs "happen to be tests" is irrelevant.
>> Yup. I have some reasoning to my madness.
> Separate pieces is good. Not sure how this properly falls into TIP except as
> a dependency. :)
"hi I want to build a distributed test execution and management
system" - I'm not worried about decoupling it until the separation of
concerns becomes clearer, and I get to you know, build it out. It's
> Seriously, how to keep protocol simple, flexible (YAML/json feel fragile),
> and extensible.
> Pick two?
Anything which makes something which must be parsed by another
language/entity will have some brittle pieces. I like YAML/JSON->Flat
text->XML in that order, but again, I'm half tempted to do it with
protocol buffers, because it's cool, and shiny.
More information about the testing-in-python