[TIP] Result protocol

[Jesse Noller]

On Sat, Apr 11, 2009 at 11:22 PM, Robert Collins
<robertc at robertcollins.net> wrote:

>
>> That's your call - I obviously like YAML (or JSON - but I don't
>> remember if JSON supports multi-line blobs). However, on a personal
>> note - I still won't be able to touch subunit, due to licensing.
>
> Could you enlarge on this?

This isn't the place, but for personal and business reasons, I avoid
contributing to GPL v2/v3/AGPL/etc code.


> Au contraire - you need a C serialiser (done, with support for check), C
> ++ serialiser (done, plugin for cppunit), perl (done, by Jelmer, but he
> isn't happy with his API yet so its in a branch indefinitely), Java
> (haven't done this yet).
>
> You only need a parser *when you are reporting* in that language.

6 of one way, half a dozen of the other - being anal, I'd want
input/output in all of the languages I was dealing with. My focus is
colored by the fact that I would be designing this in such a way to
swap any component out for non-python components, in theory.

> My sanity test for this is "if you can't do it without the wire
> protocol, you can't do it with the wire protocol". What I mean is that
> if you can't (run the same tests locally, in process, the way unittests
> run today in say nose, or even stock unittests) and (get your additional
> data) then no matter how clever or extensible the wire protocol, you are
> no longer working with unittest. Consider clock events - I haven't
> mapped this cleanly into the unittest protocol yet, and because of that
> its pretty much useless.
>

Again: I'm not concerned with playing in the xUnit sandbox. I might
like some of the organizational and other bits, but I don't want to
play by it's rules. The rules are useful until they get in my way.


> I want to fix unittest to allow it to do this; I don't care about
> reporting [in the sense of 'I have a big database and query it'] - I
> care that it is possible for someone to write a collector ('TestResult
> subclass') that inserts into a database sensibly and gathers the data
> and information we want.
>
> If 'someone' can do that without having to customise the object
> protocol, then the standard testing facilities will be sufficient for
> lots of things like pandokia to be written *and* interoperate - and
> because I will keep subunit up to date with the unittest API (which
> reminds me I need to make sure the skip support is 2.7/3.1 compatible)

Yeah, you and I have two different goals - I want to make a common
result reporting protocol, with cross language support. It's simple
enough to create Java YAML objects that fit the formatting I proposed,
same with C/Python.

Michael might have more expansive thoughts on working on unittest, but
it's not my focus.

jesse