Differences between Fit Framework Implementations

This page is an attempt to document differences between FitServer implementations for various languages, especially the things that should work but don't. (see download for instructions how to download different FitServer implementations)

1. basic fit fixtures do only inputs with fields, outputs with methods. FitLibrary fixtures do getters but not methods in general.
2. symbols with = in column headers
3. no standard way to check for exceptions
4. class and method names are case sensitive

1. methods, fields, properties all equal (can be used for inputs/outputs in basic Fit and FitLibrary fixtures
2. symbols with « and »
3. exception and error keywords can be used to check for exception classes and messages, fail[expected outcome] can be used to check whether the result is not equal to the expected outcome
4. target objects can be used with column fixture to delegate processing, similar to system under test in FitLibrary
5. class and method names are case insensitive in fixture tables

see dotnet page for more details on the .NET test runner

1. same as .Net for classic fixtures; full support for multi-parameter methods in FitLibrary.
2. support for both = column header syntax and « and » for symbols
3. error, exception and Fail implemented across the board, for both given and calculated results.
4. In 0.8 you need to subclass ColumnFixture. In the upcoming 0.9 all fixtures can use fitLibrary Domain Adapters, not just FitLibrary fixtures. This includes ColumnFixture, ActionFixture and all of the list fixtures.
5. There is a very flexible mapping mechanism between labels and identifiers, and also between fixture names in tables and module and class names on the file system. It goes way beyond case insensitivity.

see python page for more details on the python test runner

1. Fixture class has to be in a module of its own. (Cory Foy's post) The fixture class file must be in a directory named after the module. The fixture class must be in a file that is named similar to Rails convention. e.g. if the Fixture class name in the table is AcceptanceTests.FirstSecond, then the file must be in a folder called AcceptanceTests and with the name first_second.rb
2. Use names of the form my_method instead of MyMethod in the Fitnesse/HTML tables. Try this in case you have some weird 'method missing' errors
3. Ideally blank cells in a RowFixture must not be used for record comparison. On a test-run, they should be populated with the values of the corresponding attributes. See section titled 'Blank Fields' Fitnesse.org This doesn't work as on Feb 2, 2008. I jotted most of it here