Fit testing framework

[Stan James]

Is anyone out there into the Fit Testing Framework? I looked at it a while ago and was overwhelmed by the fixtures. But today I downloaded some code and looked into it further and it's pretty cool. I was able to integrate it into my own Wiki with this much code:

String tags[] = { "wikibody", "table", "tr", "td" }; 
Parse tables = new Parse(lHTML, tags);
Fixture fixture = new Fixture();
fixture.doTables(tables);
StringWriter lResult = new StringWriter();
tables.print(new PrintWriter(lResult));

Wondered if anybody was using fit or Fitnesse (currently down?) and could share advice about building fixtures. Thanks!
[ November 17, 2003: Message edited by: Stan James ]

[Ilja Preuss]

I have played a little bit with FitNesse - see http://bloodball.sf.net/
What do you want to discuss?

[Stan James]

Have you built any multi-phase tests like the Music examples on fit.c2.com? They left the results of one fixture in a public static var and used it in the next fixture, which seemed a little tacky. We could at least use ThreadLocal to avoid collisions between users.
In much the same style, I'm thinking about a first fixture that can do a variety of database queries (all yielding a common set of columns) and a second one that will assert various things about the resultset. Does that sound reasonable?

[Ilja Preuss]

Originally posted by Stan James:
Have you built any multi-phase tests like the Music examples on fit.c2.com? They left the results of one fixture in a public static var and used it in the next fixture, which seemed a little tacky. We could at least use ThreadLocal to avoid collisions between users.

Yes - I think all my tests look like that - see TestAbortTackle for an example.
You are right that using a static variable feels wrong - there is some discussion of the topic at the fit-dev list under the subject "saving state between fixtures".

In much the same style, I'm thinking about a first fixture that can do a variety of database queries (all yielding a common set of columns) and a second one that will assert various things about the resultset. Does that sound reasonable?

Yes, it does. It's a common pattern, currently known under a bunch of names - for example Build Operate Check