RE: Announce: 20061230 release of FitLibrary in Java for FitNesse

Hi Rick,
I created a unit test. There are three files:
 
MyTest.java is the unit test. It creates a html page and feeds it to
fitnesse.
MySuite.java is a simple SuiteFixture. One of its methods returns a
domain object called MyModel.
MyModel.java is the model.
Both MySuite and MyModel keep an audit trail of which of thier methods
have been called. After MyTest feeds the html to Fitnesse it looks at
the audit trail and compares it to what it exected. The expected order
of calls is:
 
MySuite.setUp(), MySuite.suite1(), MyModel.setUp(), MyModel.method1(),
MyModel.method2(), MyModel.tearDown(), MySuite.tearDown()
 
but instead I get
 
MySuite.setUp(), MySuite.suite1(), MyModel.setUp(), MyModel.tearDown(),
MyModel.method1(), MyModel.method2(),
 
Hope this helps.
Christopher
 


________________________________

From: fitnesse@... [mailto:fitnesse@...] On
Behalf Of Rick Mugridge
Sent: Tuesday, January 02, 2007 6:19 PM
To: fitnesse@...
Subject: Re: [fitnesse] Announce: 20061230 release of FitLibrary in Java
for FitNesse



Hi Chris,

I've obviously missed some test cases. I'll look into it now.

Yes, SuiteFixture depends on FitLibraryServer being used. Look at the
code in fitlibrary.spec.SpecifySuiteFixture or
fitlibrary.debug.DebugPage to see how to use FitLibraryServer directly.

Cheers, Rick

Helck, Christopher wrote:

       

        Hi Rick and other Fitnesse Folk,
         
        The new release seems to fix many of the problems I had
encountered with the delta release. Many thanks.
         
        I'm still having problems with setUp() and tearDown().
         
        I have a SuiteFixture, DoFixture, and domain object called
TdlSuite, ProtocolFixture, and ProtocolModel. My DoFixture creates the
domain object in its constructor and reuses it as needed. I notice that
the domain object's setUp() and tearDown() methods are being called
right away immediately after my DoFixute is parsed. Is this the correct
behaviour?
         
        I have these classes:
         
        public class TdlSuite extends SuiteFixture {
          public Object protocol() {
            return new ProtocolFixture();
         }
        ...
        }
         
        public class ProtocolFixture extends DoFixture {
          public ProtocolFixture() {
            super(new ProtocolModel());
          }
         
          // More methods that return various Fixtures that wrap
ProtocolModel.
          public Fixture configure { ... }
          ...
        }
         
        public class ProtocolModel {
          public void setUp() { ...}
          public void tearDown() {...}
         
          // Domain specific methods
          ...
        }
         
        My test looks like this:
         
        |com.ebs.TdlSuite|
         
        |select or | complete|
         
        |keywords | complete|
         
        |protocol|                 # Line 1
         
        |configure|
        |blah blah blah|
         
        # Following tables are normal DoFixure stuff...
        .
         
        When the test runs the ProtocolModel's setUp/tearDown methods
are both being called right after Line 1 in the test. I was hoping that
the tearDown would be called when the ProtocolFixture went out of scope
(flow?). The obvious fix for me is to move the setup/teardown logic up
into the ProtocolFixture, but I wonder what your take is on this?
         
        Happy New Year,
        Chrsitopher Helck
         

________________________________

        From: fitnesse@... [mailto:fitnesse@...]
On Behalf Of Rick Mugridge
        Sent: Friday, December 29, 2006 7:14 PM
        To: fitnesse@...
        Subject: [fitnesse] Announce: 20061230 release of FitLibrary in
Java for FitNesse
       
       

        That's available at https://sourceforge.net/projects/fitlibrary/
<https://sourceforge.net/projects/fitlibrary/>
       
        This release includes some new new capability and a fix. Changes
include
        the following. See the UserGuide included in the download zip
file for
        further details.
       
        * FitLibrary now enables debugging when running storytests.
        * CompareFileFixture now handles absolute file names as well as
        relative file names.
        * 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 domain adapter or sut 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 parse delegate may be specified for
any type,
        and so will be 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.
       
        Cheers, Rick
       
       

       

        Thank you for being part of it.

       

        The information contained in this e-mail is confidential. This
e-mail is intended only for the stated addressee. If you are not an
addressee, you must not disclose, copy, circulate or in any other way
use or rely on the information contained in this e-mail. if you have
received this e-mail in error, please inform us immediately and delete
it and all copies from your system.

       

         

        EBS Dealing Resources International Limited. Registered address:
2 Broadgate, London EC2M 7UR, United Kingdom. Registered number 2669861.

       

         

        EBS Dealing Resources, Inc, registered in Delaware. Address: 535
Madison Avenue, 24th Floor, New York, NY 10022, USA, and One upper Pond
road, Building F - Floor 3, Parsippany, NJ 07054, USA.

       

         

        EBS Dealing Resources Japan Limited, a Japanese Corporation.
Address: Asteer Kayabacho Bldg, 6th Floor, 1-6-1, Shinkawa, Chuo-Ku,
Tokyo 104-0033, Japan.