request for feedback (Re: Python FIT port )

[email protected] writes:
> Essentially, it's ready to go for a beta release. Next steps?

Hi John.. woah, good progress.

Can you subscribe to fit-dev (
http://lists.freepan.org/mailman/listinfo.cgi/fit-dev ) ?  I'll repost
your last few messages there and maybe we can get a sanity check on your
direction. Might as well since it's free.

Then it sounds like maybe we should just check in your stuff en
masse. You're happy with how it's working out, and feel this improves
things on all fronts ?  It sounds that way from here.

In fact, I include the details below. What do y'all think ?

Thank you!
-Simon



<[email protected]> writes:
> As you're no doubt aware, the FIT port you posted on fit.c2.com doesn't
> work under Python 2.2.3 and later releases. While it's a trivial three
> line fix to TypeAdapter (and I've appended the corrected module) I've
> separately taken a completely different tack in doing fixtures. I've
> appended my new ReadMe file that describes it. If you're interested,
> please contact and I'll send you the changed files. They currently run
> all three examples and the complete unit test suite (I had to make one
> change to the unit test suite, in accordance with the ReadMe.)


<[email protected]> writes:
> I've been trying to bring the package up to current specs.
> I've got the new Music example working (almost - there are
> still three places where there are one second differences.) The
> other three examples are also working. A couple more days
> will probably do it.
>
> I think I've got the base package up to specs. I need to stop
> for a moment and figure out where I am; I haven't dealt
> with FrameworkTest, RowFixtureTest, ScientificDouble, and
> Summary yet (although RowFixture and Summary seem to be
> working OK.) I haven't even looked at "fat" - the acceptance
> tests.
>
> I've done the BinaryChop example, but haven't started
> converting the All* examples, ColumnIndex, Division,
> ExampleTests, Page or Sqrt examples. And I also
> haven't looked at the net example. As I look at it,
> the ArithmeticFixture and ArithmeticColumnFixture
> also look like they were heavily redone since the
> September version.
>
> I'm not all that happy with the way I've got metadata
> spec'd out. I think we absolutely need metadata in
> the fixtures; the Music example required a specialty
> TypeAdapter for the date, so my structure was very
> handy for that.
>
> Also, it looks like I need something because the
> ExampleTests fixture overloads "wrong", and
> there isn't a good way around it other than
> renaming something. It looks like I'm going to
> have to deal with ExampleTests and AllFiles
> at the same time, though, because they both
> depend on footnotes.


<[email protected]> writes:
> Almost done bringing the package up to the March Java
> release (which I think is the latest on the Wiki.)
>
> All the tests I've found run, either exactly or with easily
> explainable differences (there are still a couple of puzzlements,
> though.) I haven't done ScientificFloat because the standard
> float type adapter now handles precision nicely. I also haven't
> done the Network example, and AllPairs uses a very different
> algorithm. It's both simpler and produces fewer cases for the
> test data. I still don't have a Date type adapter (although there
> is one embedded in the Music example, it's not in the general
> structure.)
>
> I've started work on the FitNesse interface. FitNesse
> runs fine, and I've got the Fitfilter program converted
> and running. Now to do some exploration and figure
> out how to use FitNesse...
>
> I've included a new writeup on what I've done on the
> type adapter issue. Briefly, the _typeDict approach seems
> to be doing the job. Floats have a precision entry. There's
> a generic rename ability so that the name in the table
> doesn't have to match the name in the fixture. Lists work
> (I haven't tested tuples, but I don't expect any problems
> there.) Lists and tuples have a way of specifying the type
> of the scalar entries in the _typeDict.


Version 2: 2003/07/28

General Notes:
-- This version was originally based on java version b020927,
   however, there are major changes in the reflection and 
   interface strategy: changes cannot be carried over from the
   Java version to this one without thinking about that structure.
-- Numerous changes due to shifting from a statically typed
   language that supports multi-methods to a dynamically typed
   language that does not.
-- It requires Python release 2.2 or later.
-- Example documents have a mixture of Windows and Unix line endings.
   There are tools in the Python tools directory that can convert
   one variety of line endings to the other, however, you may have
   to fiddle with the tools to get them to work in some cases. The
   actual line endings used sometimes seem to be strange.
-- The type conversion strategy has been changed since the original
   version released by Simon Michael. His use of RExec failed when
   the Python team effectively removed that facility in 2.2.3
   and subsequent. It's now much closer to the intent of the 
   original Java version. See the notes on fixtures below.

Fixture Fields and Methods.

Fixtures use a mixture of fields and methods, depending
on the specific fixture. Column fixtures use fields for
values that need to be set, and methods to retrieve values.
Action fixtures only use methods, and row fixtures use fields.
Other fixture types likewise set their own rules.

There are two special column headings. An empty cell is a comment 
column. A cell with a string beginning with a "?" character is one 
where that method has not yet been written. In the first case,
the column's background will be left white, and no counts
will be accumulated. In the second, the cell will be ignored
if it has any content. That is, the cell background will be 
greyed out and an "ignore" count will be made.

Python, unlike Java, cannot usually access type information
via the reflection API. Type information must be supplied
in a dictionary with the name "_typeDict". 

The type dictionary contains one (or more) key / value pairs
for each field or method mentioned in one of the tables.
The basic entry is simply the field or method name as the
key, and a string naming the type as the value. Currently
supported types are: "String", "Int", "Float", "Complex",
"Boolean", "List" and "Tuple". A "Date" type will be added later,
and other TypeAdapters can be added as needed.

This basic entry can also specify a subclass of TypeAdapter
rather than a string with a type name. If so, that
subclass will be used directly. This allows the fixture
writer to support odd looking types without having to add
them to the general structure in TypeAdapter.

Other entries in the dictionary have the form "Name.Attribute".
The only generic attribute is "RenameTo" used for cases
where the natural name would conflict with a name
that's already in use in the framework. For example,
the ExampleTests fixture uses both "right" and "wrong"
as column names, but these two names are also used
internally in Fixture, so some adjustment is needed.
It's unreasonable to expect the customer to make this
adjustement, nor is it reasonable to expect the developer
to change FIT to work around it.

The Float type has an attribute named "precision" that's
used to control the precision used for the compare between
the actual value and what's specified in the table.

The List and Tuple types have an attribute named "scalarType" 
that's used for the actual type of the members of the sequence.

The Date type (when it's finally constructed) will have
an attribute that controls the formatting of the date.


Fixture Names.

In general, fixture names follow the Java convention of
having a single class that is named the same as the
module. You can include more than one fixture class in a
module, though. The syntax for this is a "$" between the
module name and the class name. This is compatible with
the Java hack shown in the AllFiles example.

Directory structure.

The package is distributed as a main directory named
"fit", which has major subdirectories named "fit",
"fat" (Fit acceptance tests,) "eg" (fixtures for the
examples), "Documents" (html source for the examples),
and "Reports" (Results from running the examples). 
The programs and documents are all set up assuming that
the python path specifies the higher level "fit"
directory, not the lower level directory that
actually contains the python executables. Failing
to do this can cause wierd problems.

It would be a real good idea if the .html for the
examples contained a "<base ... > tag so that they
could get at resources like graphics when they are
moved between the "Documents" and the "Reports"
directories. This hasn't been done yet.

Acceptance test organization.

In general, FIT provides minimal assistance in
organizing your library of acceptance tests. The
basic tool is a facility for using a table to
run other tests. See the "AllFiles" example,
as well as "AllPairs and "AllCombinations."
This facility allows wild cards
in the file names. Unlike the Java verion (which
only allows an "*" as a wild card) the Python
version allows the full Unix shell "globbing" 
syntax, courtesy of the Python Standard Library.
Thanks, Guido! A little thought in setting up
your project naming standards will pay big dividends.

If you need better organization, I strongly
urge you to check out FitNesse. An interface for
the Python version of Fit is urgently needed.

Running Fit

The two main programs are: FileRunner and WikiRunner.
The difference is that WikiRunner understands the
<wiki> tag, while FileRunner doesn't. Both of these
scripts take the input .html file as the first
parameter, and the output file as the second.
In addition tests can be run recursively, from other tests.
See the AllFiles, AllCombinations and AllPairs
examples.

The output directory should have a subdirectory
named "footnotes". 

Conversion Notes:

Old fixtures **MUST** have the _typeDict added, with
appropriate type information. At the moment, I'm
gravitating to setting up all the fields in one
place at the beginning of the fixture, and placing
type information for methods either right before or 
after the method. However, I'm certainly not saying
this is "the" best way of doing it!