title: OCMock is not cleaning up stubbed class methods
body: <p>I'm trying to use OCMock to mock out internal class dependencies (e.g. my class uses an NSMutableData and verifying against a mock NSMutableData). Specifically I'm mocking factory methods to return mock objects.</p>
  
  <p>As far as I can tell the mock objects are not cleaning up class method mocks, or only cleaning them up partially. This is having pretty adverse effects on unrelated tests that may end up invoking the same class methods.</p>
  
  <p>A short example I've been able to repro locally to illustrate:</p>
  
  <pre><code>id data1 = [NSMutableData data];    // new instance
  id data2 = [NSMutableData data];    // new instance
  
  // mock +data and have it return data1
  id mock = [OCMockObject mockForClass:[NSMutableData class]];
  [[[[mock stub] classMethod] andReturn:data1] data];
  
  id foo = [NSMutableData data];  // foo == data1 ok that's good
  
  [mock stopMocking];
  mock = nil;                     // using ARC so no explicit -release
  
  id bar = [NSMutableData data];  // bar == data1, wait what? shouldn't this be new?
  </code></pre>
  
  <p>I've found the problem even worse if you mock +new. That last line where I create bar blows up with either a bad string hash or a stack overflow (I'm not sure how to consistently get one or the other, I've seen both).</p>
  
  <p>I realize there's ways around this. I could inject an NSMutableData instance into my class, which feels like overkill since it's not a hard dependency. I could have an instance method on my class that creates NSMutableData and I partially mock my class instead to inject the mock. That's fine but I would really like to know why this particular case doesn't work. Mocking internal dependencies would be quite a bit easier if I could actually stub out the factory methods!</p>
  
  <p>This issue is not limited to anything particular about NS classes (I'm aware of the limitations around mocking NSString for example) as I can repro the above issue with one of my own classes just as easily.</p>