fit_framework_implementation_differences

Trace: » galleryintroduction » subsetfixture » importfixture » flowmode » fixturegallery » summaryfixture » sourcecode » fixturearguments » resources » fit_framework_implementation_differences
This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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)
===== Java =====
  - basic fit fixtures do only inputs with fields, outputs with methods. FitLibrary fixtures do getters but not methods in general.
  - symbols with = in column headers
  - no standard way to check for exceptions
  - class and method names are case sensitive
===== .NET =====
  - methods, fields, properties all equal (can be used for inputs/outputs in basic Fit and FitLibrary fixtures
  - symbols with << and >>
  - 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
  - target objects can be used with column fixture to delegate processing, similar to system under test in FitLibrary 
  - class and method names are case insensitive in fixture tables
see [[dotnet]] page for more details on the .NET test runner
===== Python =====
  - same as .Net for classic fixtures; full support for multi-parameter methods in FitLibrary.
  - support for both = column header syntax and << and >> for symbols
  - error, exception and Fail implemented across the board, for both given and calculated results.
  - 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.
  - 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
===== Ruby =====
  - Fixture class has to be in a module of its own. ([[http://www.cornetdesign.com/2005/12/fitnesse-and-ruby-basic-tutorial.html|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
  - 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
  - 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' [[http://fitnesse.org/FitNesse.RowFixture|Fitnesse.org]] This doesn't work as on Feb 2, 2008. I jotted most of it [[http://madcoderspeak.blogspot.com/2008/02/showmethemoney-9-what-rowfixture.html|here]] 
===== Smalltalk =====
  - Fully compatible with the Java versions of Fit (1.1), FitNesse (20070619), and FitLibrary (20050923).
  - Support for later FitLibrary versions has not yet been implemented, but this is still a very functional version of FitLibrary.  Support for features labeled experimental in FitLibrary has not been implemented.
  - When running with the Fit test runner, Fit's fixture naming conventions and table markup are used.  When running with the FitNesse FitServer or command-line test runner, FitNesse's extended naming conventions ("graceful names") is supported, and FitNesse-style table markup is performed.  Additional fixtures provided by FitNesse (such as ImportFixture and TableFixture) are always available.
  - ColumnFixture and ActionFixture "fields" must be implemented as setter methods.
  - Type information is provided by implementing a method named #signatureFor:, which takes a symbol naming the field or method for which type information is required.  For fields, the name of the field is passed, not the name of the setter.
  - For fields and for methods which return a value but take no parameters, returning a Smalltalk class is sufficient.  The framework will convert the class into a FieldSignature or MethodSignature.  For more complex methods, #signatureFor: needs to return an object of class MethodSignature.  MethodSignature has a number of instance creation methods that can be used.
  - For FitLibrary's SequenceFixture (and some cases of DoFixture), methods might take parameters for which no names are provided in the table.  Use _ as the keyword in this case (for example #fill:_:).
  - FitLibrary's ParseDelegate support is not required in Smalltalk.  Any class which implements #fitParse: on the class side, and #=/#hash and #fitToString on the instance side can be directly used in FitLibrary tables.  The default implementation of #fitToString simply returns #printString, which may be sufficient in some cases.
See [[Smalltalk]] for more information
Views

Navigation

Personal Tools

Search

Toolbox
