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来暴露私有方法和属性。如: