Re: Generating C# from Java (Was: fit, nfit, et al?)

----- Original Message ----- 
From: "Charlie Poole" <[email protected]>
To: "FIT Developers" <[email protected]>
Sent: Friday, August 08, 2003 11:32 PM
Subject: RE: [Fit-dev] Generating C# from Java (Was: fit, nfit, et al?)


> Ward,
>
> > > Do all implementations work with exactly the same tables, as the Java
> > > and C# versions do?
> >
> > The goal is that if test documents required modification when
> > converting from one language to another, that the modifications would
> > seem natural given the language and/or environment, not pointless and
> > due to carelessness of the framework implementors.
> >
> > For example, the package names that appear in tables trace their roots
> > to java package names and preserve the java syntax. When this was
> > discussed on this list we considered abandoning package names and
> > searching some sort of "package path" instead. It was pointed out that
> > an implementation could always do this anyway and that having the
> > package names in the dot syntax was as good as any other syntax for
> > "advisory" package names.
>
> OK... so the package name could just be a tag in some hypothetical
> implementation. In that case, the particular fixture implementation
> that gets loaded depends on which runner is used.
>
> > I could easily imagine a whole page of framework acceptance tests (fat)
> > that discussed the conclusions of that conversation.
> >
> > I've found it convenient to write fixtures as inner classes and
> > discovered that this just worked with the java implementation using the
> > $ notation. I could easily imagine someone converting my tests to some
> > environment without inner classes having to edit those tests and cook
> > up some alternative to inner classes. This alone is probably reason for
> > me to stop using inner classes. I only did it to see what it was like.
>
> It think it would just work with the C# implementation using the +
notation.
>
> It doesn't seem like a totally bad thing if the content and format of the
> string varies a bit depending on the implementation you're using... so
long
> as the table data remains the same. That might mean some minimal set of
> data types being understood by each implementation as well, mightn't it?

Two points here. First, allowing the syntax for addressing the fixture
to vary makes customer documentation more difficult. It also makes
global acceptance tests more difficult: I would have to edit the .html
documents to fit my port (which kind of subverts the purpose of a set
of universal acceptance tests, doesn't it?) It also makes it more difficult
for projects like Fitnesse where you might very well have subprojects
in different languages on the same server with the same set of non-technical
customers.

As far as data types go, I agree thoroughly. Right now, I'm mildly
put out by the fact that Python's floating point implementation does
not support the exceptional values (NaN, inf and so forth) on
Windows. That's an exception, and it's keeping me from getting
a clean acceptance test on a couple of cases.

John Roth


>
> Charlie Poole
> [email protected]
> http://www.pooleconsulting.com
> http://www.charliepoole.org
>