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

Hi,
This is more difficult than I thought... Is there a way I can execute a
suite fixture in JUnit? It seems like FitLibraryServer is tightly
coupled to Fitnesse via FixtureBridge. I tried testing directly with
Fixture.doTables(), but this is not correct.
 
Anyway, my basic problem is that with the new release my tearDown()
method is being called at the start, and not the end of my tests.
 
Regards,
Christopher
 

________________________________

From: fitnesse@... [mailto:fitnesse@...] On
Behalf Of Helck, Christopher
Sent: Tuesday, January 02, 2007 11:31 AM
To: fitnesse@...
Subject: RE: [fitnesse] Announce: 20061230 release of FitLibrary in Java
for FitNesse



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.