为何iOS应用默认禁用Testability？测试编译失败存疑

我来帮你理清楚这个iOS测试里的Testability设置问题～

为什么默认设置会导致测试编译失败？ #

首先，当Testability选项未启用时，Xcode没办法通过动态方式把测试代码注入到你的App目标中——这可是UI测试、单元测试能正常跑起来的核心前提。如果没开这个选项，XCTest这类测试框架既没法在运行时访问App的内部类、方法，甚至连启动App开展测试的流程都会卡壳，自然就会出现编译或运行失败的情况。

为什么Debug模式下它不是默认启用的？ #

其实这个点很多开发者都吐槽过！按道理Debug模式就是为调试、测试准备的，默认开启Testability才合理，但苹果的默认配置确实没这么做——大概率是出于最小化Debug包额外开销的考虑：开启Testability会在编译时加入额外的调试符号和动态注入支持，虽然对Debug包影响不大，但苹果可能想保持默认配置的“轻量化”，把选择权交给开发者。不过现在很多项目都会手动在Debug目标里强制开启它，毕竟测试的优先级更高嘛。

启用Testability到底会带来哪些变化？ #

开启这个选项后，主要有这些关键改变：

• 允许测试框架动态注入代码：XCTest可以在App启动时把测试逻辑注入进去，不管是单元测试调用内部方法，还是UI测试操控App界面，都依赖这个能力。
• 保留完整的调试符号：编译后的App会包含更多符号信息，不仅方便测试时断点调试，也能让测试框架精准定位到App内的类和方法。
• 放宽运行时访问限制：默认情况下，App的私有方法、内部类是对外隐藏的，开启Testability后，测试代码可以绕过这些限制，直接访问内部元素——这对单元测试覆盖私有逻辑特别重要。
• 支持测试进程与主App的交互：UI测试中，测试进程和App进程需要能通信，Testability开启后，这种跨进程的调用和数据传递才会被允许。

内容的提问来源于stack exchange，提问作者Abraham P