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.
MyModel.java (600 bytes) 