Модульное тестирование NSURLConnection sendAsynchronousRequest с OCMockito

Я изо всех сил пытаюсь написать модульный тест для оболочки API с таким интерфейсом, как

- (void)publish:(id<MyCustomRequest>)aRequest completionHandler:(void (^)(id<MyCustomResponse>, NSError *)) completionBlock

который вызывает этот метод под капотом:

NSURLConnection sendAsynchronousRequest:queue:completionHandler

Вместо этого я не хочу использовать делегат, так как открытый API намного удобнее подходит для метода sendAsynchronousRequest (и не требует отдельного объекта-аккумулятора для каждого запроса). Кроме того, я использую OCMockito для насмешек над остальным кодом, который не поддерживает частичные насмешки или насмешливые методы класса.

Существуют ли какие-либо другие методы тестирования, с помощью которых я могу проверить эту функцию? Нужно ли вместо этого использовать делегата?


person Cody A. Ray    schedule 05.02.2013    source источник
comment
OCMockito поддерживает методы класса.   -  person Jon Reid    schedule 06.02.2013
comment
Да неужели? Как я могу использовать OCMockito для имитации метода класса? Я не видел этого в README или примерах.   -  person Cody A. Ray    schedule 06.02.2013
comment
Пример: Class mockStringClass = mockClass([NSString class]);   -  person Jon Reid    schedule 06.02.2013


Ответы (1)


Используйте API на основе делегатов. Я понимаю, что это больше кода, но удобный API явно не соответствует вашим потребностям (т. Е. Поддается насмешке с OCMockito). Кроме того, не беспокойтесь о «накладных расходах» на выделение одной вспомогательной функции для каждого запроса. Я совершенно уверен, что благодаря вашему вызову +[NSURLConnection sendAsynchronousRequest:queue:completionHandler:] за кулисами в рамках системы будут размещены десятки объектов. Вы не должны беспокоиться. Тем не менее, один объект может быть делегатом для более чем одного запроса, поэтому вам не обязательно иметь более одного.

person ipmcc    schedule 05.02.2013
comment
Сегодня утром попробовал API на основе делегатов, и он работает нормально, пока я позволяю ему запускаться немедленно в основной очереди. Когда я использую новую очередь, происходит что-то еще (startImmediately:NO, setDelegateQueue, start). Но это к другому вопросу, я полагаю. - person Cody A. Ray; 06.02.2013
comment
Чтобы не быть слишком очевидным, но планируете ли вы его в цикле выполнения с scheduleInRunLoop:forMode: после его инициализации? потому что иначе он никогда не запустится, поэтому ваши методы делегата никогда не будут вызваны. - person ipmcc; 06.02.2013