Re: Brain Dump of Towards FIT 1.0 OpenSpace session

----- Original Message ----- 
From: "Al Chou" <[email protected]>
To: "FIT Developers" <[email protected]>
Sent: Thursday, August 21, 2003 7:48 PM
Subject: Re: [Fit-dev] Brain Dump of Towards FIT 1.0 OpenSpace session


> --- [email protected] wrote:
> >
> > ----- Original Message ----- 
> > From: "Al Chou" <[email protected]>
> > To: "FIT Developers"
<[email protected]>
> > Sent: Thursday, August 21, 2003 7:02 PM
> > Subject: Re: [Fit-dev] Brain Dump of Towards FIT 1.0 OpenSpace session
> >
> >
> > > --- [email protected] wrote:
> > > >
> > > > ----- Original Message ----- 
> > > > From: "Al Chou" <[email protected]>
> > > > To: "FIT Developers"
> > <[email protected]>
> > > > Sent: Thursday, August 21, 2003 5:18 PM
> > > > Subject: RE: [Fit-dev] Brain Dump of Towards FIT 1.0 OpenSpace
session
> > > >
> > > >
> > > > > I couldn't find a saved message that made sense to reply to, so
I'm
> > adding
> > > > it
> > > > > to this thread.
> > > > >
> > > > > Lately I've been thinking more than usual about cross-language
> > > > compatibility,
> > > > > and I wonder whether anyone has mentioned trying to add BSF
capability
> > to
> > > > FIT
> > > > > or FitNesse so that any language that's been implemented in Java
> > (Jython,
> > > > > Tcl/Java [Jacl and/or Tcl Blend], JRuby, JScheme, and many many
> > others) or
> > > > can
> > > > > do Java FFI could be used to write fixtures.  I was pleasantly
> > surprised
> > > > to
> > > > > discover that a future version of Eclipse should have BSF
included.
> > > >
> > > > Say what? I'm having a severe case of acronoym overload. What's
> > > > a BSF, what's a FFI? I recognise Jython, so the rest of the
languages
> > > > in that clause are ok.
> > > >
> > > > In any case, Fitnesse doesn't care - writing fixtures in one
language
> > > > to drive an application in another language is a FIT issue.
> > > >
> > > > John Roth
> > >
> > > Sorry.
> > >
> > > BSF = Bean Scripting Framework, born at IBM, now at Apache
> > > http://jakarta.apache.org/bsf/
> > >
> > > FFI = foreign function interface
> > >
> > > I may have misunderstood, but I thought I had read remarks about
FitNesse
> > > calling fixtures written in languages other than Java.
> >
> > Yes, it does, but what it does is call a driver in that language in its
own
> > process (using the Java equivalent of fork) so there is no language
> > compatability issue. So, for example, there's a Java version of FIT,
> > there's a .NET version of FIT, there's a Python version of FIT,
> > and so forth. To invoke the Python versions, Fitnesse builds a
> > command something like:
> >
> > Python FitFilter.py <path stuff> <working directory>
> >
> > and passes it the HTML on its stdin, getting the result HTML
> > by reading the stdout and stderr.
> >
> > John Roth
>
>
> Thanks for the clarification, John.  OK, so let's substitute "FIT" for
> "FitNesse" in my original question.  Rather than (or in addition to, for
those
> languages that have no Java compatibility) having FIT re-implemented in
> numerous languages, why not have one core FIT that allows fixtures to 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 the
older style fixtures.

The other difficulty I see is that you'd need a JVM, which isn't
needed for any other purpose if you're not running FitNesse. And
that makes is more difficult to modify FIT if your team doesn't
do Java.

How would you handle type adapters? That whole mechanism
is inherently language specific, which means they would have to
be reimplemented on the target language side.


> The original FIT is in Java, which
> happens to have a lot of other languages implemented in it, but as long as
an
> interface was exposed that many other languages could work with, it
wouldn't
> matter what language the core FIT was written in (a recent thread on
Ruby-talk
> brings to mind the possibility that rather than exposing an
> implementation-language-specific [e.g., Java or C] API, the public
interface
> could be XML-RPC, SOAP, or some other already-language-neutral
technology).

No way do I want something as heavyweight as those two! AFIC, anyone
who's trying to do acceptance testing with FIT across a network connection
from the program under test is, to put it mildly, working way too hard and
needs a vacation - desperately.

A much more lightweight text-based protocol would do fine. If you have to
have XML, so be it, but I consider it major overkill when all you need 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