Brain Dump of Towards FIT 1.0 OpenSpace session

Ward called an OpenSpace meeting to come up with ideas for the formal FIT 1.0 release. We had about a dozen attendees, including me (John Roth) representing Python, someone to whom I offer abject apologies for forgetting their name (please speak up and identify yourself) representing the C++ port, and Charlie Poole who had lots of suggestions for the C# port. We also had one person who was thinking of porting FIT to Fortran.

I'm calling this a brain dump, because that's what it is: Ward has the flip charts, and he went right to join his family on a long delayed and well earned vacation in the wilds of somewhere that I like to read of in travel books.

So, what I remember, and at risk of misremembering:

1. We agreed that, as far as possible, the HTML should be completely portable between different language ports. While there may be places where this is not possible, we should strive mightily to minimize them, partially by removing Javaisms from the spec.

2. We need a consistent way of getting type information for type adapters. While Java's reflection facility (and I believe C#'s as well) can return the necessary type information, languages like Python and Ruby don't have type information to return, and languages like C++ and Fortran don't have a reflection facility at all! Parenthetically, the C++ implementation uses a macro to build a table of methods and types, while the new (unreleased at this point) Python version stores type information in a dictionary in each fixture. The old (released) Python version uses the compiler's run-time expression parsing facility (exec, eval and friends) to do dynamic determination, which we all agreed was not sufficient.

3. We discussed field names as seen by the user. We need a good method of specifying which fields store data, and which ones retrieve it. The current convention of using "()" after the name to indicate data retrieval seems a bit programmerish for a user facility, but nobody had a better idea. Also, we need to be consistent: the column fixture does both store and retrieve, while the row fixture only retrieves data, and what the action fixture does depends on the specific command.

4. We discussed a possible include fixture. I think that it can be done in a fixture, without any changes to the core.

5. We discussed how to have non-FIT tables in the same document as FIT tables. There were a number of use cases involving management of the portfolio of acceptance tests, as well as other application dependent functions.

6. Fixture naming. We didn't like the idea of fixtures having to have path expressions (and Charlie said that the path expressions didn't map to C#, even conceptually!) The basic notion was that a fixture name should mean something to the customer, and the implementation should have some way of mapping it to a location in the file system. This also resolves the "$" that Ward used to locate inner classes in the Java version: it shouldn't matter if a fixture is a main class, an inner class, or something that's specific to Ruby or Python rather than Java.

7. We need a set of acceptance tests for FIT 1.0 that all of the implementations need to adhere to. Some of the examples aren't really acceptable for acceptance tests: the Python version can't duplicate the Java version's behavior on the arithmetic example, because it depends on the way Java mangles integer arithmetic when it overflows. Python has (conceptually) infinite precision integers, so it can't overflow. Likewise, Python has trouble with floating point exceptional values.

8. Speaking of exceptions, there was a lot of confusion about "error", and when a blank field meant a blank character string, and when it meant a value that shouldn't be stored, and when it meant to store a Null (Nil, None, etc) value. Suggestions (preferably with a blinding flash of insight to resolve the problem in a consistent, user friendly way) will be gratefully accepted.

9. FitNesse interface. We thought that having one in the core was an excellent idea, but we also didn't want to limit it only to Fitnesse. Likewise, we found issues with identifying both the fixture (i.e. project) library, and the test library. These need to be resolved.

10. Properties. Java doesn't have them, C# does, Python does in 2.2 and later, and Ruby doesn't seem to allow direct access to instance variables except through methods (I think - I'm not a Ruby expert.) The big issue with properties is that storing a value can cause an exception / error, which is something that the current architecture doesn't seem to take into account.

11. Setup and teardown as separate documents that are merged into the test document.

12. The ability to use something other than the file system to store tests: that is, use the same version control system that the development system uses.

13. Elimination of the  <wiki> tag. Ward agrees that it was a mistake (well, a quick and dirty workaround. At least, I now understand what he was thinking about!)

And one that I thought of after the session:

A. We need a supported method of saving state between fixtures in a single test.

And several ideas that have been mentioned on the FitNesse list, that I won't enumerate here.

John Roth

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