几周前，我决定将将我在 mokacoding 上的创作更多集中在单元测试与验收测试，自动化和生产效率上，主要在iOS领域。
相关深入文章可以看看“通过 CocoaPods 为 iOS 项目创建 Calabash 并构建配置”和“用终端运行 Xcode 测试”。
这周我们要回过头来看看，或者说是站在更高的角度审视单元测试和验收测试，以及在云端运行持续集成有哪些资源。
就像有人创建 walking skeleton 时会做的事情一样，我们也将先查看 Cocoa 和 Xcode 提供给开发者的工具，然后再看看能实现更好效果的开源库，最后整理出在云端持续集成环境运行测试的解决方案。
Xcode，测试开始的地方
伴随着 iOS 7 和 Xcode 5，苹果发布了 XCTest，一个简单而又强大的测试编写框架，使用了同 xUnit 一样的风格。
编写 XCTest 测试很简单，开发者在 Xcode 点击 ⌘U 运行测试便能持续不断地迅速获得反馈。
Xcode 还有一个叫“Test Navigator”的界面，它可以让我们看到所有测试点，包括在最后一次运行后的成功或失败状态。
值得注意的是，红色为测试失败，绿色为测试通过。在不断迭代过程中颜色会给你很大帮助。
XCTest 已经高度集成在 Xcode 中，使用简单方便。这是它主要优点，也是缺点。XCTAssert 类 API 并不容易理解，也不灵活。从 Xcode 外边运行测试也没有你想象的那么简单。
在过去两年中，iOS 和 OS X 的单元测试框架已经变得越来越好，而验收测试这边反而没什么进步。
苹果提供了 UIAutomation 框架来编写 UI 自动化测试。UIAutomation 测试使用 javascript 写成。允许用户使用代码驱动应用 UI 并给它的状态设置断言。尽管看上去很美好，使用 UIAutomation 其实是很繁琐的， javascript API 也没有原生代码写成的单元测试那样强大。
这是 UIAutomation 测试的一个小片段。
|
1 2 3 4 5 |
UIATarget.localTarget().frontMostApp().navigationBar().buttons()["Add"].tap(); UIATarget.localTarget().frontMostApp().mainWindow().tableViews()[0].cells()[0].elements()["Chocolate Cake"]; UIATarget.localTarget().frontMostApp().mainWindow().tableViews()[0].scrollToElementWithPredicate("name beginswith 'Turtle Pie'"); |
你可以看到的，javascript API 比 Foundation 中的那些更加冗长。再加上这种测试需要在 Instruments 中运行，你就可以想象使用这个框架是多么的不爽。
最后是苹果的 CI 解决方案：Xcode Bots。我们可以配置一个 Xcode Bot，在需要的时候触发他工作，例如运行我们的测试，Xcode Bots 可以存放在服务器端。
我承认我自己并没有用过 Xcode Bots，但是我获得的所有反馈都告诉我这个东西并不好用。
总结下，如今缺乏好奇心的开发者和大公司，可以只使用苹果的技术，组建一整套运行在CI的单元测试和验收测试。用于工作基本上是足够了。
如果你正在阅读本文，你可能充满了好奇心，那么让我们继续看看开源社区有那些资源。
开源单元测试框架
iOS 和 OS X 开源社区充满了各种大牛和有趣的项目。在写本文的时候，在 pod 上一共有 8625 个开源项目。
这些单元测试的开源库主要都是行为描述风格（xSpec），一定程度上也反映了测试风格的一种趋势，这风格来自于 Ruby 测试库的 RSpec， 主要是测试类的行为，而不是枚举方法。
Kiwi
Kiwi 是一个全栈式的，XCTest的代替品，支持行为描述句式。实例代码如下
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
describe(@"Team", ^{ context(@"when newly created", ^{ it(@"has a name", ^{ id team = [Team team]; [[team.name should] equal:@"Black Hawks"]; }); it(@"has 11 players", ^{ id team = [Team team]; [[[team should] have:11] players]; }); }); }); |
Kiwi 测试用例通常非常容易阅读和理解代码所想要测试的内容，他就像一个好的说明文档。
Kiwi 集成了一些测试方法 期望（expectations）, 模拟对象 (mock)，桩程序 (stub)，甚至还支持异步测试。
Specta
Specter 跟 Kiwi 非常像，但是它使用了不同的架构。Kiwi 是庞大的代替品 ，Specta 优势则体现在模块化与组件化。这个库关心的唯一事情是编写和运行 xSpec 风格的测试，然后用户可以根据使用期望（expectations）， 匹配（matching），模拟对象（mock）和桩程序（stub）的情况来补充相应模块。
我个人更喜欢这个库的设计，轻量级，包含的多个模块可以被结合在一起。
这是 Specta 行为描述
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
SpecBegin(Thing) describe(@"Thing", ^{ it(@"should do stuff", ^{ // This is an example block. Place your assertions here. }); it(@"should do some stuff asynchronously", ^{ waitUntil(^(DoneCallback done) { // Async example blocks need to invoke done() callback. done(); }); }); }); |
注意 it 执行的时候 blocks 是空的。留给库的使用者来用他们喜欢的工具填写。
说到工具，这里有一个库名单，他们都可以与 Specta 和 Kiwi 配合使用：
Expectaa matcher framework, expect(foo).to.equal(bar).OCHamcrestanother matcher framework, assertThat(foo, equalTo(bar)).OCMocka mocking framework.OCMockitoanother mocking framework.OHTTPStubsa library to stub network requests, with block based syntax to match URLs.Nocillaanother library to stub network requests, with a nice chain-able API, stubRequest(@”POST”, ).withHeaders(…).withBody(…).
Quick
Quick 是一个新的测试框架，也相当炫酷的一个。主要代码都是用 Swift 写的，非常适合用新的语言写测试组件。
|
1 2 3 4 5 6 7 8 9 10 11 |
import Quick 几周前，我决定将将我在 mokacoding 上的创作更多集中在单元测试与验收测试，自动化和生产效率上，主要在iOS领域。 相关深入文章可以看看“通过 CocoaPods 为 iOS 项目创建 Calabash 并构建配置”和“用终端运行 Xcode 测试”。 这周我们要回过头来看看，或者说是站在更高的角度审视单元测试和验收测试，以及在云端运行持续集成有哪些资源。 就像有人创建 walking skeleton 时会做的事情一样，我们也将先查看 Cocoa 和 Xcode 提供给开发者的工具，然后再看看能实现更好效果的开源库，最后整理出在云端持续集成环境运行测试的解决方案。 Xcode，测试开始的地方伴随着 iOS 7 和 Xcode 5，苹果发布了 XCTest，一个简单而又强大的测试编写框架，使用了同 xUnit 一样的风格。 编写 XCTest 测试很简单，开发者在 Xcode 点击 ⌘U 运行测试便能持续不断地迅速获得反馈。 Xcode 还有一个叫“Test Navigator”的界面，它可以让我们看到所有测试点，包括在最后一次运行后的成功或失败状态。
值得注意的是，红色为测试失败，绿色为测试通过。在不断迭代过程中颜色会给你很大帮助。 XCTest 已经高度集成在 Xcode 中，使用简单方便。这是它主要优点，也是缺点。 在过去两年中，iOS 和 OS X 的单元测试框架已经变得越来越好，而验收测试这边反而没什么进步。 苹果提供了 UIAutomation 框架来编写 UI 自动化测试。UIAutomation 测试使用 javascript 写成。允许用户使用代码驱动应用 UI 并给它的状态设置断言。尽管看上去很美好，使用 UIAutomation 其实是很繁琐的， javascript API 也没有原生代码写成的单元测试那样强大。 这是 UIAutomation 测试的一个小片段。
你可以看到的，javascript API 比 Foundation 中的那些更加冗长。再加上这种测试需要在 Instruments 中运行，你就可以想象使用这个框架是多么的不爽。 最后是苹果的 CI 解决方案：Xcode Bots。我们可以配置一个 Xcode Bot，在需要的时候触发他工作，例如运行我们的测试，Xcode Bots 可以存放在服务器端。 我承认我自己并没有用过 Xcode Bots，但是我获得的所有反馈都告诉我这个东西并不好用。 总结下，如今缺乏好奇心的开发者和大公司，可以只使用苹果的技术，组建一整套运行在CI的单元测试和验收测试。用于工作基本上是足够了。 如果你正在阅读本文，你可能充满了好奇心，那么让我们继续看看开源社区有那些资源。 开源单元测试框架iOS 和 OS X 开源社区充满了各种大牛和有趣的项目。在写本文的时候，在 pod 上一共有 8625 个开源项目。 这些单元测试的开源库主要都是行为描述风格（xSpec），一定程度上也反映了测试风格的一种趋势，这风格来自于 Ruby 测试库的 RSpec， 主要是测试类的行为，而不是枚举方法。 KiwiKiwi 是一个全栈式的，XCTest的代替品，支持行为描述句式。实例代码如下
Kiwi 测试用例通常非常容易阅读和理解代码所想要测试的内容，他就像一个好的说明文档。 Kiwi 集成了一些测试方法 期望（expectations）, 模拟对象 (mock)，桩程序 (stub)，甚至还支持异步测试。 SpectaSpecter 跟 Kiwi 非常像，但是它使用了不同的架构。Kiwi 是庞大的代替品 ，Specta 优势则体现在模块化与组件化。这个库关心的唯一事情是编写和运行 xSpec 风格的测试，然后用户可以根据使用期望（expectations）， 匹配（matching），模拟对象（mock）和桩程序（stub）的情况来补充相应模块。 我个人更喜欢这个库的设计，轻量级，包含的多个模块可以被结合在一起。 这是 Specta 行为描述
注意 it 执行的时候 blocks 是空的。留给库的使用者来用他们喜欢的工具填写。 说到工具，这里有一个库名单，他们都可以与 Specta 和 Kiwi 配合使用：
QuickQuick 是一个新的测试框架，也相当炫酷的一个。主要代码都是用 Swift 写的，非常适合用新的语言写测试组件。
|
