如何在开发过程中正确创建可测试的场景？答案

【问题标题】：How to properly create testable scenarios during development?如何在开发过程中正确创建可测试的场景？
【发布时间】：2014-06-27 21:49:16
【问题描述】：

在将 Google 的 Cast SDK 实现到 iOS 应用程序时，我遇到了这个问题，无法提出可扩展、高效的解决方案，但我想一定有比我聪明的人能给我一个几个想法：

Google 的 Chromecast iOS SDK 带有一个 GCKDeviceScanner 类，用于管理可用投射接收器（即 Chromecast HDMI 加密狗）的发现。为了解决这个问题，显然最好是在一个房间里，将 Chromecast 插入已打开电源的电视。

但是，这可能并不总是可行的，依赖可用的网络资源也不会使代码易于测试。为了解决这个问题，我创建了MockGCKDeviceScanner（GCKDeviceScanner 的子类）并重写了适用的方法，以便将假接收器设备返还给我以进行开发/测试。现在，即使没有可用的物理接收器，我也可以继续编码。

但我发现集成到我的实际课程中相当麻烦。在上面的例子中，我有一个

@property (nonatomic, strong) GCKDeviceScanner *scanner

但是，在实际初始化时，我正在做这个相当丑陋的解决方法：

#ifdef kDevMode
_scanner = [[MockGCKDeviceScanner alloc] init];
#else
_scanner = [[GCKDeviceScanner alloc] init];
#endif

这看起来不太好......并且使我的代码阅读起来非常麻烦。这样做的正确方法是什么？

【问题讨论】：

标签： ios objective-c xcode tdd chromecast

【解决方案1】：

您是如何进行测试的？你在使用任何框架吗？

一个选项是定义两个不同的方案，每个选项一个。其中之一可以在方案中定义一个系统变量，该变量将在运行时用于决定为测试加载哪个类

【讨论】：

我正在使用 XCTest 进行测试。但更重要的是，我想知道如何在开发过程中进行测试（这里：如果周围没有物理设备）。

【解决方案2】：

您可以通过构造函数“inject”扫描器，将具体类的选择推迟到调用者。

根据对象图中的深度，您可能还需要某种locator 对象，代价是引入全局引用。

【讨论】：