[TIP] Nosejobs!

[Jesse Noller]

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

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

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

>>> 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
all related.


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

http://code.google.com/apis/protocolbuffers/


jesse