Quick
Quick是建立在XCTestSuite上的框架，使用XCTestSuite允许你动态创建测试用例。所以，使用Quick,你仍让可以使用XCode的测试相关GUI和命令行工具。
使用Quick编写的测试用例看起来是这样子的：
import Quick import Nimble class TableOfContentsSpec: QuickSpec { override func spec() { describe("the 'Documentation' directory") { it("has everything you need to get started") { let sections = Directory("Documentation").sections expect(sections).to(contain("Organized Tests with Quick Examples and Example Groups")) expect(sections).to(contain("Installing Quick")) } context("if it doesn't have what you're looking for") { it("needs to be updated") { let you = You(awesome: true) expect{you.submittedAnIssue}.toEventually(beTruthy()) } } } } } |
BDD的框架让测试用例的目的更加明确，测试是否通过更加清晰。使用Quick,测试用例分为两种：
单独的用例 - 使用it来描述
it有两个参数，
行为描述
行为的测试代码
比如，以下测试Dolphin行为，它具有行为is friendly和is smart
//Swift代码 class DolphinSpec: QuickSpec { override func spec() { it("is friendly") { expect(Dolphin().isFriendly).to(beTruthy()) } it("is smart") { expect(Dolphin().isSmart).to(beTruthy()) } } } |
可以看到，BDD的核心是行为。也就是说，需要关注的是一个类提供哪些行为。
用例集合，用describe和context描述
比如，验证dolphin的click行为的时候，我们需要两个用例。一个是is loud,一个是has a high frequency，就可以用describe将用例组织起来。
class DolphinSpec: QuickSpec { override func spec() { describe("a dolphin") { describe("its click") { it("is loud") { let click = Dolphin().click() expect(click.isLoud).to(beTruthy()) } it("has a high frequency") { let click = Dolphin().click() expect(click.hasHighFrequency).to(beTruthy()) } } } } } |
context可以指定用例的条件：
比如
describe("its click") { context("when the dolphin is not near anything interesting") { it("is only emitted once") { expect(dolphin!.click().count).to(equal(1)) } } } |
除了这些之外，Quick也支持一些切入点，进行测试前的配置：
●beforeEach
●afterEach
●beforeAll
●afterAll
●beforeSuite
●afterSuite
●Nimble
由于Quick是基于XCTest，开发者当然可以收使用断言来定义测试用例成功或者失败。Quick提供了一个更有好的Framework来进行这种断言：Nimble
比如，一个常见的XCTest断言如下：
XCTAssertTrue(ConditionCode, "FailReason")11
在出错的时候，会提示
XCAssertTrue failed, balabala
这时候，开发者要打个断点，查看下上下文，看看具体失败的原因在哪。
使用Nimble后，断言变成类似
expect(1 + 1).to(equal(2))
expect(3) > 2
expect("seahorse").to(contain("sea"))
expect(["Atlantic", "Pacific"]).toNot(contain("Mississippi"))
并且，出错的时候，提示信息会带着上下文的值信息，让开发者更容易的找到错误。
让你的代码更容易单元测试
测试的准确性和工作量很大程度上依赖于开发人员的代码质量。
通常，为了单元测试的准确性，我们在写函数(方法)的时候会借鉴一些函数式编程的思想。其中最重要的一个思想就是
pure function(纯函数)
何为Pure function？就是如果一个函数的输入一样，那么输出一定一样。
比如，这样的一个函数就不是pure function。因为它依赖于外部变量value的值。
static NSInteger value = 0; - (NSInteger)function_1{ value = value + 1; return value; } |
而这个函数就是pure function，因为给定输入，输出一定一致。
- (NSInteger)function_2:(NSInteger)base{ NSInteger value = base + 1; return value; } |
所以，如果你写了一个没有参数，或者没有返回值的方法，那么你要小心了，很可能这个方法很难测试。
关于MVC
在良好的MVC架构的App中，
View只做纯粹的展示型工作，把用户交互通过各种方式传递到外部
Model只做数据存储类工作
Controller作为View和Model的枢纽，往往要和很多View和Model进行交互，也是自动化包括代码维护的痛点。
所以，对Controller瘦身是iOS架构中比较重要的一环，一些通用的技巧包括：
逻辑抽离：
网络请求独立。可以每个网络请求以Command模式封装成一个对象，不要直接在Controller调用AFNetworking。
数据存储独立。建立独立的Store类，用来做数据持久化和缓存。
共有数据服务化（协议）。比如登录状态等等，通过服务去访问，这样服务提供者之需要处理服务的质量，服务使用者则信任服务提供者的结果。
Controller与View解耦合
建立ViewModel层，这样Controller只需要和ViewModel进行交互。
建立UIView子类作为容器，将一些View放到容器后再把容器作为SubView添加到Controller里
建立可复用的Layout层，不管是AutoLayout还是手动布局。
Controller与Controller解耦合
建立页面路由。每一个界面都抽象为一个URL，跳转仅仅通过Intent或者URL跳转，这样两个Controller完全独立。
如果你的App用Swift开发，那么面向协议编程和不可变的值类型会让你的代码更容易测试。
当然，iOS组建化对自动化测试的帮助也很大，因为不管是基础组件还是业务组件，都可以独立测试。组建化又是一个很大的课题，这里不深入讲解了。
KIF
KIF的全称是Keep it functional。它是一个建立在XCTest的UI测试框架，通过accessibility来定位具体的控件，再利用私有的API来操作UI。由于是建立在XCTest上的，所以你可以完美的借助XCode的测试相关工具（包括命令行脚本）。
> KIF是个人非常推荐的一个框架，简单易用。
使用KIF框架强制要求你的代码支持accessibility。如果你之前没接触过，可以看看Apple的文档
Accessibility Programming Guide for iOS
简单来说，accessibility能够让视觉障碍人士使用你的App。每一个控件都有一个描述AccessibilityLabel。在开启VoiceOver的时候，点击控件就可以选中并且听到对应的描述。
通常UIKit的控件是支持accessibility的，自定定义控件可以通过代码或者Storyboard上设置。
在Storyboard上设置：
上面的通过Runtime Attributes设置（KVC）
下面的通过GUI来设置
通过代码设置：
[alert setAccessibilityLabel:@"Label"]; [alert setAccessibilityValue:@"Value"]; [alert setAccessibilityTraits:UIAccessibilityTraitButton]; |
如果你有些Accessibility的经验，那么你肯定知道，像TableView的这种不应该支持VoiceOver的。我们可以用条件编译来只对测试Target进行设置：
#ifdef DEBUG [tableView setAccessibilityValue:@"Main List Table"]; #endif #ifdef KIF_TARGET (这个值需要在build settings里设置) [tableView setAccessibilityValue:@"Main List Table"]; #endif |
使用KIF主要有两个核心类：
KIFTestCase XCTestCase的子类
KIFUITestActor 控制UI，常见的三种是：点击一个View，向一个View输入内容，等待一个View的出现
我们用KIF来测试添加一个新的ToDo
- (void)testAddANewItem{ [tester tapViewWithAccessibilityLabel:@"Add"]; [tester enterText:@"Create a test to do item" intoViewWithAccessibilityLabel:@"Input what you want todo"]; [tester tapViewWithAccessibilityLabel:@"Save"]; [tester waitForTimeInterval:0.2]; [tester waitForViewWithAccessibilityLabel:@"Create a test to do item"]; } |
命令行
自动化测试中，命令行工具可以facebook的开源项目：
xctool
这是一个基于xcodebuild命令的扩展，在iOS自动化测试和持续集成领域很有用,而且它支持-parallelize并行测试多个bundle，大大提高测试效率。
安装XCTool,
brew install xctool11
使用
path/to/xctool.sh \
-workspace YourWorkspace.xcworkspace \
-scheme YourScheme \
-reporter plain:/path/to/plain-output.txt \
run-test
并且，xctool对于持续集成很有用，iOS常用的持续集成的server有两个：
Travis CI 对于公开仓库（比如github）免费，私有仓库收费
Jenkins 免费
优化你的测试代码
准确的测试用例
通常，你的你的测试用例分为三部分：
配置测试的初始状态
对要测试的目标执行代码
对测试结果进行断言（成功 or 失败）
测试代码结构
当测试用例多了，你会发现测试代码编写和维护也是一个技术活。通常，我们会从几个角度考虑：
不要测试私有方法（封装是OOP的核心思想之一，不要为了测试破坏封装）
对用例分组（功能，业务相似）
对单个用例保证测试独立（不受之前测试的影响，不影响之后的测试），这也是测试是否准确的核心。
提取公共的代码和操作，减少copy/paste这类工作，测试用例是上层调用，只关心业务逻辑，不关心内部代码实现。
一个常见的测试代码组织如下：
appium
appium采用了Client Server的模式。对于App来说就是一个Server，基于WebDriver JSON wire protocol对实际的UI操作库进行了封装，并且暴露出RESTFUL的接口。然后测试代码通过HTTP请求的方式，来进行实际的测试。其中，实际驱动UI的框架根据系统版本有所不同：
< 9.3 采用UIAutomation
>= 9.3 XCUITest
原因也比较简单：Apple在10.0之后，移除了UIAutomation的支持，只支持XCUITest。
对比KIF，appium有它的优点：
跨平台，支持iOS，Android
测试代码可以由多种语言编写，这对测试来说门槛更低
测试脚本独立与源代码和测试框架
当然，任何框架都有缺点：
自定义控件支持不好
WebView的支持不好
总结
由于我不是专业的iOS测试，关于测试的一点见解如下：
单元测试还是选择BDD框架，毕竟可读性高一些，推荐Quick（Swift），Kiwi(Objective C)
UI测试优先推荐KIF，如果需要兼顾安卓测试，或者测试人员对OC/Swift很陌生，可以采用appium
