[BUG?] MC creates mock classes but doesn't quite destory them

Daniel Vainsencher danielv at netvision.net.il
Sat Sep 13 21:06:31 UTC 2003


I wouldn't be surprised if this is a bug in a system call to remove
classes, because a friend of mine seems to be seeing a symptom like that
in loading the Chronology package. Would be a worthwhile bug to catch if
that is so.

Daniel

Colin Putney <cputney at wiresong.ca> wrote:
> 
> 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



More information about the Squeak-dev mailing list