OCMockito crash when mocking KVO observer

Question

Я пытаюсь высмеять объект, который передается моему SUT. При передаче SUT регистрирует макет как наблюдателя для некоторых свойств. В SUT dealloc он вызывает removeObserver на макет. Это отлично работает с OCMockito 0.23, но при обновлении до 1.0.0 этот тест заставляет OCMockito попасть в [HCIsEqual .cxx_destruct]. Отладка немного, приводит меня к MKTInvocationContainer методе:

- (void)setInvocationForPotentialStubbing:(NSInvocation *)invocation 

, в котором вызов сказано, чтобы сохранить свои аргументы. Может быть цикл удержания?

Кроме того, я делал некоторые исследования, и я нашел несколько ответов SO Констатируя несовместимость между NSProxy и КВО:

NSProxy and Key Value Observing

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

Однако, интересно, почему это работает с OCMockito 0,23 и не сейчас. Есть идеи?

Решение в моем случае - заменить макет реальным объектом. Это прекрасно работает, но больно создавать целый объект для тестового набора, который его почти не использует.

В любом случае, если KVO не поддерживается с помощью mocks, я считаю, что это должно быть документировано и надлежащим образом обработано.

[EDIT]

Я нашел обходной путь для этой проблемы.

Мы используем специализированную инфраструктуру KVO на основе блоков, аналогичную описанной здесь: http://www.mikeash.com/pyblog/key-value-observing-done-right.html. Теперь SUT регистрирует макет для KVO, передавая self внутри блока. Я считаю, что self где-то где-то сохраняется, но его не должно быть, поскольку оно слабое перед блоком ...

Использование исправления по умолчанию kvo, предоставляемого Apple, похоже, устраняет эту проблему. Тем не менее, меня все еще беспокоит основная проблема. Что изменилось в OCMockito, что делает это неудачным сейчас?

В любом случае, извините за беспокойство и большое спасибо.

Answer 1

Я бы сказал, что лучший способ узнать - запустить git bisect на OCMockito. Это поможет вам отследить, какой именно битмит нарушил ваш код.

Вот Руководство страница git bisect: https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

А вот официальный учебник: http://git-scm.com/book/en/Git-Tools-Debugging-with-Git

В вашем случае вы будете делать что-то вроде:

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

Когда вы знаете, какие совершают сломал ваш тест, попытайтесь выяснить, какие изменения произошли в коммит, которые его нарушили. Тогда, пожалуйста, вернитесь и сообщите нам, что вы узнали, чтобы мы могли выяснить, можно ли исправить это для следующего выпуска или нет.

Если у вас есть тестовый проект, который раскрывает эту ошибку, я бы не прочь сделать для вас деление пополам (по крайней мере, если мне скучно и у меня будет время).