[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
|