On Friday, September 12, 2003, at 07:22  AM, Daniel Vainsencher wrote:

> For example, after running all tests for a while -
>
> MCMock subclasses <print it>
> #(MCMockClassB MCMockDependentItem MCMockClassA MCMockClassA
> MCMockClassB MCMockClassA MCMockClassB MCMockClassA MCMockClassB
> MCMockClassA MCMockClassB MCMockClassA MCMockClassB MCMockClassA
> MCMockClassB MCMockClassA MCMockClassB MCMockClassA MCMockClassB).
>
> This might be a bug in the tests, but I don't know well enough who
> destroys the mocks there...

Whoa. My MC development image has 186 subclasses of MCMock. This 
probably has something to do with the tests for loading snapshots. The 
#tearDown for all the tests that manipulate the mocks works by loading 
a snapshot taken at the beginning of the test run. (See 
MCSnapshotResource.) In most cases, this should be a noop, because the 
definition already active in the image matches the definition in the 
snapshot being loaded. There are a few tests, however, that first 
*unload* the mocks to test that loading them works correctly when 
they're not already present.

So this may be a bug in the unload code. AFAIK, that code is only 
called by the MC tests, so it's unlikely to show up in normal usage of 
MC. Have you noticed this with any other (non-mock) classes?

I'll do some digging and see if I can track this down.

Colin