Как один модуль тестирует код, который взаимодействует с базовыми API-интерфейсами Bluetooth?

Question

Я бы хотел, чтобы блок тестировал класс, который действует как CBPeripheralManagerDelegate классу CBPeripheralManager. Как правило, для того, чтобы заглушить внешнюю зависимость класса, я бы использовал либо форму инъекции зависимости, проходя через инициализатор класса, либо через свойство. При работе с API на основе однопользовательских я могу использовать библиотеки, такие как Kiwi, чтобы заглушить метод уровня класса, который возвращает singleton (т. Е. [ClassName stub:@selector(sharedInstance) andReturn:myStubbedInstance]). Проблема в случае издевательств CBPeripheralManager заключается в том, что ее инициализатор принимает экземпляр делегата. Таким образом, любой код, который использует мой класс должен был бы сделать что-то вроде этого:

PeripheralManagerWrapper *wrapper = [[PeripheralManagerWrapper alloc] init]; 
CBPeripheralManager *peripheralManager = [[CBPeripheralManager alloc] initWithDelegate:wrapper queue:nil options:nil]; 
wrapper.peripheralManager = peripheralManager; 

Тогда для модульного тестирования мой PeripheralManagerWrapper класс, я мог бы просто создать его экземпляр и передать в издевался CBPeripheralManager. Тем не менее, мне не нравится, если бы какой-либо вызывающий код моего объекта-обертки должен был пройти эту настройку. Есть ли лучший образец для решения этой ситуации? Я использовал оба Kiwi и OCMockito, но ни один из них не обеспечивает эту функциональность, возможно, затухание методов alloc и initCBPeripheralManager, а затем просто создает экземпляр экземпляра в инициализаторе .

Answer 1

ИМХО, основные интерфейсы Bluetooth идеально подходят для модульного тестирования. Все обратные вызовы делегата принимают менеджера и соответствующие параметры, поэтому, если вы следуете шаблону, в котором используете эти аргументы, вместо внутреннего состояния, вы сможете передать все, что захотите. Использование макетных объектов - лучший способ сделать это. Во время модульного тестирования вы не должны пытаться издеваться над поведением менеджеров. Вы должны сосредоточиться на проверке взаимодействия вашего кода с API и ничего более.

Упаковщики могут лучше удовлетворять интеграционным испытаниям. Но на самом деле, интеграционное тестирование Core Bluetooth-кода лучше сделать вручную для моего опыта. Стек не достаточно стабильна, чтобы обеспечить надежное тестирование, и тестовый код также должен быть усилен против ошибок стека, что действительно сложно, поскольку, очевидно, они не документированы или не предсказуемы, просто просматривая API. Хотя, с другой стороны, ваш тестовый код должен будет также моделировать ошибочное поведение стека. Могут быть случаи, когда это возможно, но тестовый код будет таким же сложным, если не больше, чем код, который вы тестируете.