core-jgi/fitnesse/FitNesseRoot/FitLibrary/WhatIsNew/From2006To2008Fixturing/content.txt

!2 20080702
 * Added support for Do macros.
 * Enabled the use of fixture class names while in flow
 * Included ''!-FitNesse-!'' plugin support for suite fixtures and macros. This means that a ''!-SuiteSetUp-!'' page is run, if it exists up the page hierarchy, when a single storytest is run.
!2 20070225
 * Added support for Batch running of ''!-FitNesse-!'' storytests with ''!-TestRunner-!''. See BatchWithFitNesse.
 * Fixed a substitution bug with storytest templates
 * Added a check for an element of a collection being null, and now give a useful error message
!2 20070217
Added support for:
 * Variables. See .FitLibrary.UserGuide.FitLibraryByExample.VariAble
 * Templates.
For ''!-FolderRunner-!'', included the pre-jdk1.4 version of the Fit classes from ''!-FitNesse-!''
!2 20070128
 * Added support for parsing of any type. See .FitLibrary.SpecifiCations.ParserSpecifications.EntityParser.FinderAsSpecialisedParser
!2 20070119
 * Release for both ''!-FitNesse-!'' and ''!-FitLibraryRunner-!'' supporting ''!-FolderRunner-!''
 * Added support for direct read access to class fields (ie, instance variables), including non-public ones. If a getter is not available for a property, a check is made for a field.
  * This brings ''!-FitLibrary-!'' closer to the way that Hibernate handles object access. It means that a getter doesn't need to be provided only for testing with storytests, and the field can remain private (or whatever).
 * Improved error reporting with ''!-FolderRunner-!''
!2 20070110
 * Release of ''!-FitLibraryRunner-!'', supporting ''!-FolderRunner-!''
 * Updated the Fit book examples to be consistent with the latest package structure
 * Release of ''!-FitLibrary-!'' for ''!-FitNesse-!''
 * When using ''!-FitLibraryServer-!'' with ''!-FitNesse-!'':
  * Normally, tables in some storytests that pass are not reported by ''!-FitNesse-!''.
  * The first two storytests are reported in full, so that you can see the full report for a single storytest by running it.
  * However, when running ${suite}, all storytests are reported in full.
  * This is to reduce the socket traffic between ''!-FitNesse-!'' and ''!-FitLibraryServer-!'' so as to reduce the likelihood of ''!-FitNesse-!'' hanging partway through running a Suite.
!2 20070104
 * A ${fixturingMethod} is no longer called on a ${sut}.
 * ${suiteSetUpMethod} and ${suiteSetUpMethod} methods are called on a ${suite}, at the beginning and end of processing of the whole suite.
!2 20061230
 * ${fitLibrary} now enables debugging when running storytests. See .FitLibrary.UserGuide.FaQ4Programmers.DebugCapability
 * ''!-CompareFileFixture-!'' now handles absolute file names as well as relative file names. See .FitLibrary.UserGuide.FitLibraryByExample.SpecialisedTables.FileComparison
 * An empty tables cell may be interpreted as follows, depending on what value the cell is expected to hold:
  * An empty list, set, array, map
  * A null value for an object, including Integer, etc
 * ${fitLibrary} accesses private getter/setters for properties. This allows for setter injection without generally exposing properties.
 * ${fitLibrary} accesses private nullary constructors. This allows for object creation without generally exposing the constructor.
 * use of HR to separate phases of ${domainFixture}
 * The method that is called for a calculation rules may return an object that's a subtype of the declared return type of the method. The actual type of the result is used to check it against the expected value
 * Fixed problem with a ''startUp()'' method being called more than once for suite fixtures, etc.
 * Lots of storytests have been added to check that exceptions are caught correctly and nulls are handled correctly
 * '''Experimental feature''': If it exists, the method ''startCreatingObject()'' of a ${domainAdapter} is called when ${domainFixture} (and other fixtures) automatically create an object; the object is passed as an argument. This allows for specialised setup of the object before it has property values automatically injected into it. The corresponding method ''endCreatingObject()'' is called at the end of automatic injection.
 * '''Experimental feature''': A ${parseDelegate} may be specified for any type, and so will override any provided ${parser} for that type for the duration of the storytest concerned.
 * '''Experimental feature''': A revised mechanism for supporting polymorhism is included. I will later add support for tailoring the way that the type is specified in the table.  The documentation is still to be completed.
 * '''Only relevant to those who write their own fixtures:''' The interpretation cycle passes extra type information; this is used in ''!-FitLibrary2-!'' to track the generic types of objects (which is missing at runtime, due to ''erasure'' in Java). The way that Parsers are selected has been changed considerably. Some class names have been changed, and the package structure has changed in minor ways. ''!-FitLibraryServer-!'' has changed considerably.
!2 20060906delta
This release contains many changes.
 * It is a ''delta'' release because of the large number of changes and because some recent additions are not well documented
 * In this release, if the first class name in the first table of a ${storytest} is not a Fixture (or a ${traverse}), it is automatically wrapped with a ${domainFixture}, a new, extended ''!-DoFixture-!''
!3 Change from Fixture to Traverse
 * ${fitLibrary} is now organised around ${traverse}s instead of Fixtures.
  * For the most part, for each ''X''Fixture there is now a corresponding ''X''Traverse.
  * However, in some cases, there are name changes. ''!-SetUpFixture-!'' maps to ${collectionSetUpTraverse}. ''!-DoFixture-!'' maps to ${workflowTraverse}.
  * Some new ${traverse}s don't have a corresponding fixture (eg, ''!-ArrayTraverse-!'').
  * However, as we cover below, there's no need to know about the particular classes
 * This change, and others in the implementation of ${fitLibrary}, were made to enable larger-scale refactorings and the continuing evolution of ${fitLibrary}.
  * The previous dependencies of ${fitLibrary} on the finer details of the ${fit} implementation were making this difficult.
 * ${fitLibrary} continues to inter-operate with ${fit} and to support existing Fixtures.
!3 Handling of maps and arrays
 * See ${mapTraverse}
 * See ${arrayTraverse}
!3 Simplified and generalised code for setup tables
 * ''!-SetUpFixture-!'' continues to be supported as it was in previous releases
  * This required that a subclass have a ${objectFactoryMethod} that creates an object for each row of the table and adds it to a collection
 * The replacement is ${collectionSetUpTraverse}:
  * See .FitLibrary.SpecifiCations.CollectionSpecifications.CollectionSetUpTraverse
  * With this, it's not necessary to subclass
  * Instead, call ''!-FitLibrarySelector.selectCollectionSetUp()-!'' with a ''List'' or ''Set''.
  * The ${objectFactoryMethod} creates an object for each row and returns it. That object is automatically added to the collection
  * To set up a ''Map'', use the old technique.For further details, see .FitLibrary.SpecifiCations.CollectionSpecifications.CollectionSetUpTraverse
!3 Domain Adapters
 * It is no longer necessary to subclass or explicitly use fixtures/traverses. See the code in FitLibraryByExample for examples.
!3 Specifying how a table is to be interpreted
Most of the time, there's no need to specifically mention the code that will interpret a table:
 * If the method for a ${workflow} action returns a List, Set, array, Map, Object, etc, it will be ${autoWrapped} with an appropriate fixture/traverse
 * You may want to use a specific fixture/traverse in your code. For example, you may prefer to have a ''!-SetTraverse-!'' manage a ''Map'' instead of ''!-MapTraverse-!'', the default. Rather than referring to the specific fixture or traverse, call the appropriate factory method in ${selector}.
!3 Change to fixture class hierarchy
 * ''!-CalculateFixture-!'', ''!-ConstraintFixture-!'', and ''!-CombinationFixture-!'' no longer subclass ''!-DoFixture-!''
!3 Fixtures and ${traverse}s: Implementation Detail
 * This is only relevant to you if you have written fixtures that depend on the finer implementation details of ${fitLibrary}
 * The implementation of ${fitLibrary} has been drastically changed
 * A Traverse carries out a similar function to a Fixture: interpreting a table in some way. However, the implementation of a Traverse is somewhat different from a Fixture. A Traverse is not a subclass of Fixture.
 * The ''!-FitLibrary-!'' fixtures are now implemented in terms of ${traverse}s
 * ''!-TypeAdapter-!'' has been replaced by ${parser}, which generalises the parsing and matching of the contents of table cells, including nested tables.
 * ''Parse'' has been replaced by ''Tables'', ''Table'', ''Row'', ''Cell'' for better encapsulation and clearer code
 * ''Counts'' has been replaced by ''!-TestResults-!'' for better encapsulation. Unlike with ''Counts'', ''!-TestResults-!'' are passed through as arguments in internal method calls in ${traverse}, etc
 * Special methods in ''!-DoFixture-!'' (and ${workflowTraverse} now take two arguments: (''Row'',''!-TestResults-!'') instead of one: (''Parse'')
 * As stated above, these change in the implementation of ${fitLibrary} were made to enable larger-scale refactorings and the continuing evolution of ${fitLibrary}. The previous dependencies of ${fitLibrary} on the finer details of the ${fit} implementation were making this difficult.
----
!3 20060610
 * The error messages for unfound methods are more explicit about where the methods are expected to be
 * It is no longer necessary to subclass the supplied ''!-FitLibrary-!'' fixtures. See DomainAdapter.
 * Method names derived from table headers can be mapped programmatically, both in a fixture subclass and in a ''DomainAdapter''. See MethodNameMappings.
!2 20060219
 * Distributed with the ''!-FitNesse-!'' release Of August 2006
 * Suite fixtures added. See .FitLibrary.SuiteFixture and .FitLibrary.SpecifiCations.SuiteFixture for further details
!2 20060116
fitlibrary20060116.jar and fitlibraryRunner20060116.jar
 * ''!-DoFixture.SetUpTearDown-!'' extended
 * setUp() and tearDown() added to ''!-CalculateFixture-!'', ''!-ConstraintFixture-!'' and ''!-CombinationFixture-!''
 * This user guide reorganised, splitting out experimental parts
!2 20060111
fitlibrary20060111.jar
 * ''!-DoFixture-!'' methods ''setUp()'' and ''tearDown()''
 * ''!-FolderRunner-!'' now allows for BODY tags with extra information in them, as generated by MS-Word (it adds extra information to a report for CSS to show colored tags)