我想对充当 CBPeripheralManagerDelegate 到 CBPeripheralManager 类的类进行单元测试。通常，为了消除外部类依赖，我会使用一种依赖注入(inject)形式，通过类初始值设定项或属性传入。在处理基于单例的 API 时，我已经能够使用像 Kiwi 这样的库来 stub 返回单例的类级方法(即 [ClassName stub:@selector(sharedInstance) andReturn:myStubbedInstance]) .模拟 CBPeripheralManager 的问题是它的初始化程序采用委托(delegate)实例。所以任何使用我的类的代码都需要做这样的事情:
PeripheralManagerWrapper *wrapper = [[PeripheralManagerWrapper alloc] init];
CBPeripheralManager *peripheralManager = [[CBPeripheralManager alloc] initWithDelegate:wrapper queue:nil options:nil];
wrapper.peripheralManager = peripheralManager;
然后，为了对我的 PeripheralManagerWrapper 类进行单元测试，我可以简单地实例化它并传入模拟的 CBPeripheralManager。但是，我不喜欢要求我的包装器对象的任何调用代码都必须经过此设置。有没有更好的模式来处理这种情况？我同时使用过 Kiwi 和 OCMockito，但似乎都没有提供此功能，可能只是将 CBPeripheralManager 的 alloc 和 init 方法 stub ，然后只是在 PeripheralManagerWrapper 中实例化实例
的初始值设定项。
最佳答案
恕我直言，Core Bluetooth API 非常适合单元测试。所有委托(delegate)回调都采用管理器和相关参数，因此如果您遵循使用这些参数而不是内部状态的模式，那么您将能够传递任何您想要的东西。使用模拟对象是最好的方法。在进行单元测试时，您不应该试图模仿经理的行为。您应该专注于验证您的代码与 API 的交互，仅此而已。
包装器可能更适合集成测试。但实际上，根据我的经验，Core Bluetooth 代码的集成测试最好手动完成。堆栈不够稳定，无法进行可靠的测试，而且测试代码也必须针对堆栈错误进行强化，这确实很难，因为很明显，这些错误没有记录在案，也无法仅通过查看 API 来预测。另一方面，您的测试代码也必须模拟堆栈的错误行为。可能存在可能的情况，但测试代码将与您正在测试的代码一样复杂。
关于objective-c - 一个单元测试代码如何与核心蓝牙 API 交互？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21336643/