[TIP] Result protocol
jnoller at gmail.com
Sun Apr 12 07:21:52 PDT 2009
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.
More information about the testing-in-python