5. UITest测试总结

1. 什么是Mock

当我们在做单元测试的过程中，为了保持测试又短又快和测试的隔离性，希望尽可能少地去实例化一些具体的组件。在现在面向对象的系统中，被测试的对象很可能会依赖于几个其他的对象，这时候我们就可以使用Mock去代替实例化这些对象。简单来说，Mock就是在测试中伪造的具有预定行为的具体对象的替身对象。因为被测试对象无法分辨出具体对象和替身对象的差别，所以可以用替身对象去代替具体对象执行测试。

2. 使用Mock的好处

构造一些使用具体对象难以构造或难以出现的对象。如我们朝服务器（第三方服务器）发送请求，也许100次中只返回一次Error，而当我们要测试返回Error情况下的系统的行为是否符合预期，使用具体对象完成比较困难，这时候就需要构造MockObject。

减少一些耗时的操作，例如我们需要测试访问数据库，而访问这个数据库开销巨大的时候，我们可以构造一个“虚拟”的数据库，让这个数据库返回我们期望的特定值即可。

甚至有时候因为需要内网或者屏蔽等原因，无法连接服务器的情况，也可以使用“虚拟”一个网络连接或服务器，让它返回我们期望的数据即可。

3. 测试框架简介

XCTest Or GHUnit

	XCTest	GHUnit
简述	苹果官方提供的测试框架	相对热门的第三方测试框架
优点	与XCode深度集成，无需安装，而且可以享受苹果后续的维护	有自己的GUI界面，测试结果直观
缺点	测试结果难找且信息冗杂	集成度不如XCTest，安装麻烦，不能单独运行某个测试

XCTest和GHUnit都有各自的优缺点，相对来说GHUnit所提供的便利意义并不大，所以更多的开发者会选择XCTest。

以下是一些Github上的一些知名的开源库的测试框架选择：

Expect Or OCHamcrest

	Expecta	OCHamcrest
简述	两者都是断言的扩展框架，都依赖于CocoaPods	起源于Java的Hamcrest，OCHamcrest是Hamcrest的一个Objective -C版本
优点	断言不必考虑数据类型，可读性强，使用方便	框架成熟，预定义的断言更加丰富，可自定义断言，可扩展性高
缺点	预定义断言不够多，可扩展性不高

TDD Or BDD Or Not

TDD 的全称是Test Driven Development，也就是测试驱动开发。它与软件传统的先开发后验证的模式不同，是先验证后开发。举个例子来说，师傅砌砖，在TDD模式下会先拉线后砌砖，这样砌出来的砖都是整齐的。而一些新来的师傅可能会先砌砖，然后再拉线检查砖是否整齐，若砖不整齐，再继续做后续的工作。这样一听，感觉TDD是不是很厉害，但实现起来非常困难。

BDD的全称是Behavior Driven Development，也就是行为驱动开发，通过测试来推动整个开发的进行。BDD的理念是描述行为，所以感觉不是在写代码，而是在讲故事。因此BDD的测试开发语言都十分接近自然语言，可读性非常强，让有眼前一亮。现有的BDD框架大多由三部分构成（Given....When....Then....)组成，下面是一段Objective-C语言的BDD框架Kiwi的一段测试代码：

这个测试用例就是在说Give a Team, when newly created, it should have a name, and should have 11 players. 翻译成中文就是一个足球队成立的时候，它应该有一个队名和11位球员。基本不用注释就能很容易的读懂这个测试做了什么。BDD框架的语法差别不大，十分易读。目前iOS相关的BDD开源热门框架有：

框架名称	测试语言	GitHub Stars	备注
Kiwi	Objective-C	3223	Kiwi自带Mock功能，是基于OCMock实现的，所以不能和OCMock共用
Specta	Objective-C	1692	Kiwi可以看做是带有Mock和Expecta功能的Specta
Quick	Swift(Objective-C)	4698
Sleipnir	Swift	795
Cedar	Objective-C	1079

对于BDD框架的选择，使用或不使用更多开发的项目。BDD测试代码可读性高，不过相对于XCTest和OCMock的组合，具有一定的学习成本且文档不如后者丰富，在封装过程中也失去了一定的灵活性。

目前使用过的BDD框架Kiwi和Specta都不支持单独运行某个测试样例，只能使用Command+U一次运行所有测试样例，当测试样例逐渐增多的时候就不得不运行一些不想要做的测试。

4. OCMock简介

如果你已经理解了什么是Mock，那么OCMock就是Objective-C语言下的一个Mock框架。目前OCMock的版本是OCMock3，其API不太多，使用起来方便，这里简单介绍一些：

Mock的模式：

模式	描述	API
Strict Mode	严格类型的Mock，当Mock对象调用了没有被Stub的方法会抛出异常。即严格意义上的完全Mock。	id strictMock = OCMStrictClassMock([NSUserDefaults class]);
Nice Mode	友好类型的Mock，当Mock对象调用了没有被Stub的方法不会抛出异常。目前是默认的Mock类型。	id niceMock = OCMClassMock([NSUserDefaults class]);
Partial Mode	部分类型的Mock，当Mock对象调用了没有被Stub的方法会直接执行具体对象的方法。	NSUserDefaults *defs = [NSUserDefaults standardUserDefaults]; id partialMock = OCMPartialMock(defs);

Expect-Run-Verify 和 Verify after running

大多数的Mock框架都遵循了Expect-Run-Verify的原则，老版本的OCMock就是其中之一，这种方法出现了一些弊端。OCMock3支持了一种新的验证方法Verify After Running，我们不用在运行结束就立即去验证结果。只要在运行之后，只要在想要验证的时候调用OCMVerify即可。

NSInvocation

在OCMock中如果使用了Block绑定参数，那么就需要和NSInvocation打交道，在Objective-C中，NSInvocation有两个默认的参数(0: self , 1:_cmd)，在绑定参数的时候要从2开始算。如：

- (void)downloadWeatherDataForZip:(NSString *)zip callback:(void (^)(NSDictionary *response))callback;

如果要动态绑定Callback，那么它对应的序号应该是3(0: self, 1: _cmd, 2: zip, 3: callback)。

通过[invoke getArgument:&storageVariableName atIndex:3];即可。

5. UI Tests相关

待补

6. Unit Tests相关

处理私有方法和属性

按照测试的原理，我们不应该去测试私有的方法。但在我们测试的时候可能会调用一个私有方法或者私有属性，如果不将其改为公有是无法去验证这些行为的。这种情况，我们可以在测试文件的开头用一个名为UnitTest的Category来暴露私有方法和属性。如：

7. 相关页面

wwdc 2015 session UI Testing PDF

UITests Tutorial