2

I'm trying to mock an object that is passed to my SUT. When passed, the SUT registers the mock as observer for some properties. In SUT dealloc, it calls removeObserver on the mock. This was working just fine with OCMockito 0.23, but when updating to 1.0.0, this test makes OCMockito to get trapped in [HCIsEqual .cxx_destruct]. Debugging a little bit, lead me to MKTInvocationContainer method:

- (void)setInvocationForPotentialStubbing:(NSInvocation *)invocation

in which the invocation is told to retain its arguments. Could be a retain cycle?

Furthermore, I've been doing some research and I found several SO answers stating the incompatibility between NSProxy and KVO:

NSProxy and Key Value Observing

https://stackoverflow.com/a/17457155/2824409

However, I wonder why this was working with OCMockito 0.23 and not now. Any idea?

The solution in my case is to replace the mock with a real object. This works fine, but it is painful to build a whole object for a test suite that barely uses it.

At any case, if KVO is not supported with mocks, I believe this should be documented, and properly handled.

[EDIT]

I found a workaround for this problem.

We are using a custom block based KVO infrastructure, similar to the described here: http://www.mikeash.com/pyblog/key-value-observing-done-right.html. Now, SUT is registering the mock for KVO, passing self inside a block. I believe self is being retained somewhere, but it shouldn't be, since it is weakified before the block...

Using the default kvo framework provided by Apple seems to fix this problem. However, I'm still worried about the underlying problem. What changed in OCMockito that makes this fail now?

Anyway, sorry for the trouble and thank you very much.

Community
  • 1
  • 1
César Estébanez
  • 21
  • 3

1 Answers1

0

I would say that the best way to find out is to run git bisect on OCMockito. This will help you track down exactly which commit broke your code.

Here's the Manual page for git bisect: https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

And here's the official tutorial: http://git-scm.com/book/en/Git-Tools-Debugging-with-Git

In your case you will do something like:

$ git bisect start
$ git bisect bad v1.0.0
$ git bisect good v0.23

When you know which commit broke your test, try to figure out exactly what change within the commit that broke it. Then please come back and let us know what you found out, so that we can figure out whether it is possible to fix this for the next release or not.

If you have a test project that exposes this bug I wouldn't mind doing the bisecting for you (at least not if I'm bored and have time).

Erik B
  • 40,889
  • 25
  • 119
  • 135