RE: 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