苹果公司终于决定在今年的 WWDC 上对用户界面进行加倍测试，让我们深入到 API 看看我们能发现什么.
背景我从事于 IOS 测试已经有几个年头了，在进入 BeerMenus 之前，我在 Pivotal 呆了两年，Pivots， 我们更愿意这样被称呼， 严谨测试.。作为测试驱动开发公司 (或者 TDD 公司)， Pivots花时间来测试每一个角落裂缝。尽管代码的覆盖率并不是最优先级的，它们很容易包含95%，并不全是这样的项目。
Cedar
回到 Xcode 4，测试 iOS 应用的唯一方式就是 OCUnit，其遗留了许多有待改进之处。Pivots 利用了它们在 行为驱动开发（behavior-driven development）框架中的专业观点着手创建它们自己的测试套件 - Cedar 诞生了.
Cedar 是一个优秀的框架，用于创建 BDD 风格的测试，完全支持匹配器和伪装。而 Xcode 7 还没有完全的支持，Pivotal 在一个分支上跟进他们的工作，预计很快就会有东西要发布了。自从尝到 TDD 的甜头之后， 我使用 Cedar 测试过我所工作过的每一个 iOS 应用。我甚至开始把它用在功能测试控制器上，但那是下次的主题了。
单独使用 Cedar 不能给与我在使用 Ruby on Rails 时所日渐赞赏的端到端覆盖。我不能可靠地在几个屏幕之间进行触摸操作，让应用运作起来。可以理解的是，Cedar 并不用为那个而被创建出来的。为了填补这个空缺，许多玩家都已经创建了他们自己的第三方功能测试框架。
第三方测试
Frank， KIF， Subliminal， Apple 的 UIAutomation，我把他们都试了一遍。你要是希望了解更多可以访问我的故障特征测试框架。它不是开发者的失败，而是因为 Apple 对待测试只有有限的开放性。这使得这些框架有一系列的补丁，而在这些补丁之上，这些框架不外乎都成为了一堆破碎的工具。
没有涉及到的更多细节：
Frank 一直被遗弃。
KIF 已经与主要的 iOS 修订版本决裂。
Subliminal 不能在命令行中可靠地运行。
UIAutomation 是用 JavaScript 和 clunky 写的。
我在 Pivotal 工作的时候，有六个分离的 app，我尝试对每个不同应用使用不同的框架。我甚至对 KIF 和 Frank 捐助，因为我希望这些框架成功。不幸地是，它们不可能离开 Apple 的支持。
WWDC 2015
今年的 WWDC 带来了好消息：在各平台进展状态介绍环节对用户界面测试进行了介绍。
Xcode 7 引入了用户界面测试，旨在确保您在代码中所做的修改，不会向您的用户呈现出乎意料的效果。
Wil Turner 和 Brooke Callahan 在第 406 节展示了新框架，Xcode 中的 UI 测试。如果你还没有看过它，建议去看一看。他们演示了一个简单的任务管理应用，对工具中的一些 API 和功能进行了高亮显示。
UI 测试的重头戏是“记录”。在你有了一个要位置工作的应用程序之后，点击一个大红圈，然后开始在你的 app 里面到处点击。当你正在与 app 交互时，代码会被自动生成出来以重现你的操作流程。理论上，之后你就能够运行新创建的测试，并看着 app 重复你之前的动作。
UI 测试实战
自卖自夸是一回事，在真实世界中这个框架会起作用吗?
文档
