Re: saving state between fixtures

----- Original Message ----- 
From: "Micah Martin" <[email protected]>
To: "'FIT Developers'" <[email protected]>
Sent: Monday, August 18, 2003 5:25 PM
Subject: RE: [Fit-dev] saving state between fixtures


> > Other than that, I think the location is exactly correct - a
> > second hash
> > in Fixture that would allow storing state would be exactly correct. In
> > fact, using a hash opens up the intreguing idea of using it
> > as a symbol
> > table.
> >
>
> This is what I suggested a while back.  Michael Feathers made a good
> point.... How is this done in C++ where there is no common Object base
> class?
>
> One tangent to this idea, that Ward put into my head, is to keep track of
> all the Fixtures that have been run.  Similar to the summary hash, each
> Fixture would put itself into a Fixture History list or hash.  Then any
> Fixture would have access to all previously executed Fixtures.  In this
> reguard each Fixture would be responsible for remembering state and
> retrieving state from other Fixtures.
>
> Further thoughts...(read at your own risk)
>
> fit.Summary could use the Fixture History list to generate the summary.
> Which suggests that maybe the summary hash is not needed.  But then you
> wouldn't be able to easily insert information into the summary.  That is
> unless FIT were to load all the Fixtures first,  and execute them second.
> That opens up alot of possibilities; perhaps too many.
>
> Micah

Interesting way of looking at it. We already have a table list as
part of Parse, except that it isn't backward chained and it doesn't
have a slot of type Object for the fixture to use. I don't see any essential
difficulty with the summary, either. Right now, FIT generates a separate
Summary object for each table, and merges them into the result summary
as the table finishes. This is simply a slight extension of that process.

John Roth