Re[2]: Brain Dump of Towards FIT 1.0 OpenSpace session

I was getting ready to make a suggestion, but then I realized that I
had already written it up a while ago.  I offer these thoughts in the
sincerest hope that they can help:

http://www.artima.com/weblogs/viewpost.jsp?thread=8826


Michael Feathers


fjc> ----- Original Message ----- 
fjc> From: "Al Chou" <[email protected]>
fjc> To: "FIT Developers" <[email protected]>
fjc> Sent: Friday, August 22, 2003 2:16 AM
fjc> Subject: Re: [Fit-dev] Brain Dump of Towards FIT 1.0 OpenSpace session


>> > > Thanks for the clarification, John.  OK, so let's substitute "FIT" for
>> > > "FitNesse" in my original question.  Rather than (or in addition to,
fjc> for
>> > those
>> > > languages that have no Java compatibility) having FIT re-implemented
fjc> in
>> > > numerous languages, why not have one core FIT that allows fixtures to
fjc> be
>> > > written in whatever language you choose?
>> >
>> > It's an interesting thought. You'd need an interface program in the
>> > target language, though. You'd also need to do a considerable amount
>> > of reengineering of the FIT core, and you'd have to insure that the
>> > new style fixtures weren't substantially more difficult to write than
fjc> the
>> > older style fixtures.
>>
>> I guess the re-engineering might be in the form of having some core
fjc> facility
>> that would parse the HTML tables and send the meaning of the data therein
fjc> to
>> the fixture (so as not to be forced to implement type adapters in every
>> language in which one wants to write fixtures, as you mention below).
fjc> There's
>> some perhaps difficult decoupling of the functionality in the current
fjc> concept
>> of a fixture that would need to be done.  Or maybe implementing type
fjc> adapters
>> in a language is the price that language's users have to pay in order to
fjc> play
>> with FIT.  It's less coding than re-implementing _all_ of FIT in the
fjc> target
>> language, right?

fjc> Since the FIT core doesn't have access to the fixtures, there's no way
fjc> it can know what the actual data types are without a lot of communication
fjc> at the start of table interpretation. Also, it makes it very difficult to
fjc> handle
fjc> language and application specific type adapters.

fjc> I don't see enough benefit to justify the additional complexity. In fact,
fjc> at one point I thought of pushing type conversion to the fixtures
fjc> themselves; the fixtures, after all, know what's needed better than some
fjc> global framework. It's still an idea that has a bit of an appeal.

>> Though it just occurred to me that if the interface/protocol used to
>> communicate table data between the FIT core and the fixtures included a
fjc> set of
>> standard data types (reminiscent of XDR; or better, a set of
fjc> self-describing
>> data types, perhaps based on a core set of primitive types [such as n-byte
>> integers, for integral types]), then type adapters could be implemented
fjc> just
>> once for all, and the main thing that would have to be provided per
fjc> language is
>> the protocol interpreter/translator.

fjc> Standard data types are something we have to put up with when we're
fjc> coupling systems built by different organizations to what are supposedly
fjc> common specs. They are not something we should have to limit ourselves
fjc> to in a test framework that is supposed to be customer friendly.

>> > A much more lightweight text-based protocol would do fine. If you have
fjc> to
>> > have XML, so be it, but I consider it major overkill when all you need
fjc> is to
>> > transfer tables and counts back and forth.  A CSV variant would work
>> > just fine.
>> >
>> > The more I think about it, the more I like it. There are a bunch of
>> > possibilities here, I think.
>> >
>> > John Roth
>>
>> That's fine, I was just trying to point out possibilities that were new,
fjc> at
>> least to me.  I agree that there's no need for a heavy protocol yet, if
fjc> ever.

fjc> Here's a first cut at a protocol. It's basically a comma separated values
fjc> (CSV)
fjc> with one cell per line.

fjc> Data sent to the language dependent stub have four fields:
fjc> 1. table number - integer
fjc> 2. row number - integer
fjc> 3. column number - integer
fjc> 4. content - character string with certain characters (comma, nl, lf, cr,
fjc> esc) escaped.

fjc> Data returned from the language dependent stub has more fields:

fjc> 1. table number - integer
fjc> 2. row number - integer
fjc> 3. column number - integer
fjc> 4. status - specific character values (see below)
fjc> 5. returned value - character string (depends on status)

fjc> status values:

fjc> input-accepted (no return value)
fjc> input-error message (error message returned)
fjc> input-exception (stack trace returned)

fjc> output-accepted (no returned value)
fjc> output-incorrect (returned value)
fjc> output-error message (error message returned)
fjc> output-exception (stack trace returned)

fjc> ignored (no returned value)

fjc> However, there's a special case return for an inserted row:

fjc> 1. I - literal character capital I
fjc> 2. new row number - integer, counts from the last row in the original table
fjc> 3. after row number - integer, row to insert this row after.

fjc> Inserted columns are implicit; if the column number exceeds the
fjc> highest number currently in the row, the row is extended.

fjc> Escaping is always an issue with CSV, that's why there are so
fjc> many different minor and incompatible variations out there!
fjc> The escape character is a backslash.

fjc> B - Backslash
fjc> C - Comma
fjc> n - new line
fjc> r - carriage return
fjc> l - line feed

fjc> Note that to produce a backslash, you code \B, ***NOT*** \\,
fjc> and to produce a comma, you produce \C, not \,.
fjc> The reason for this rather unusual spec is that it makes the
fjc> <string>.split(",") method work properly with the lines.
fjc> The reasoning for the backslash is a bit murkier, but has to
fjc> do with simplifying regex replacements.

fjc> Another issue: ASCII or UTF-8? I'm leaning toward
fjc> UTF-8, but I don't know how much trouble it would cause
fjc> for other languages. Java is obviously cool, so is
fjc> Python and I'd be very surprised if .NET couldn't handle
fjc> it with ease. Ruby? Perl?

fjc> Comments?

fjc> John Roth






>>
>> Al
>>
>> =====
>> Albert Davidson Chou
>>
>>     Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
>>
>> __________________________________
>> Do you Yahoo!?
>> Yahoo! SiteBuilder - Free, easy-to-use web site design software
>> http://sitebuilder.yahoo.com
>>
>> _______________________________________________
>> Fit-dev mailing list
>> [email protected]
>> http://lists.freepan.org/mailman/listinfo.cgi/fit-dev


fjc> _______________________________________________
fjc> Fit-dev mailing list
fjc> [email protected]
fjc> http://lists.freepan.org/mailman/listinfo.cgi/fit-dev



-- 
Best regards,
 Michael                            mailto:[email protected]