前言
维基百科对单元测试的定义如下：
在计算机编程中，单元测试（英语：Unit Testing）又称为模块测试, 是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。
在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
根据不同场景，单元的定义也不一样，通常我们将C语言的单个函数或者面向对象语言的单个类视作测试的单元。在使用单元测试的过程中，我们要知道这一点：
单元测试并不是为了证明代码的正确性，它只是一种用来帮助我们发现错误的手段
单元测试不是万能药，它确实能帮助我们找到大部分代码逻辑上的bug，同时，为了提高测试覆盖率，这能逼迫我们对代码不断进行重构，提高代码质量等。
内置单元测试框架
在Xcode4.x中集成了测试框架OCUnit，根据测试的目的大致可以将单元测试分为这三类：
- 性能测试：测试代码执行花费的时间
- 逻辑测试：测试代码执行结果是否符合预期
- 异步测试：测试多线程操作代码
在我们新建项目的时候，已经默认选择创建单元测试的框架，除了Unit Tests之外还有一个UI Tests是iOS9推出的新特性，针对UI界面的单元测试框架。在创建项目之后，会自动生成一个appName+Tests的文件夹目录，下面存放着单元测试的文件
一个标准的测试类文件代码如下。其中setUp会在每一个测试用例开始前调用，用来初始化相关数据；tearDown在测试用例完成后调用，可以用来释放变量等结尾操作；testPerformanceExample中的会将方法中的block代码耗费时长打印出来；最后的testExample用来执行我们需要的测试操作，正常情况下，我们不使用这个方法，而是创建名为test+测试目的的方法来完成我们需要的操作：
在每个测试用例方法的左侧有个菱形的标记，点击这个标记可以单独的运行这个测试方法。如果测试通过没有发生任何断言错误，那么这个菱形就会变成绿色勾选状态。使用快捷键command+U直接依次调用所有的单元测试。另外，可以在左侧的文件栏中选中单元测试栏目，然后直观的看到所有测试的结果。同样的点击右侧菱形位置的按钮可以运行单个测试方法或者文件：
另外，为了保证单元测试的正确性，我们应当保证测试用例中只存在一个类或者只发生一个类变量的属性修改。下面是我们测试中常用的宏定义
|
1
2
3
4
5
6
|
XCTAssertNotNil
(
a1
,
format…
)
当
a1不为
nil时成立
XCTAssert
(
expression
,
format
.
.
.
)
当
expression结果为
YES成立
XCTAssertTrue
(
expression
,
format
.
.
.
)
当
expression结果为
YES成立；
XCTAssertEqualObjects
(
a1
,
a2
,
format
.
.
.
)
判断相等，当
[
a1
isEqualTo
: a2
]返回
YES的时候成立
XCTAssertEqual
(
a1
,
a2
,
format
.
.
.
)
当
a1
==
a2返回
YES时成立
XCTAssertNotEqual
(
a1
,
a2
,
format
.
.
.
)
当
a1
!=
a2返回
YES时成立
|
逻辑测试
笔者新建了一个用以测试的model类，该类提供了三个接口。需要注意的是，在逻辑测试的某个操作步骤前后，应该有对应的数据发生了改变，这样才能够方便我们进行测试：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
@interface
LXDTestsModel
: NSObject
@property
(
nonatomic
,
readonly
,
copy
)
NSString
*
name
;
@property
(
nonatomic
,
readonly
,
strong
)
NSNumber
*
age
;
@property
(
nonatomic
,
readonly
,
assign
)
NSUInteger
flags
;
+
(
instancetype
)
modelWithName
:
(
NSString
*
)
name
age
:
(
NSNumber
*
)
age
flags
:
(
NSUInteger
)
flags
;
-
(
instancetype
)
initWithDictionary
:
(
NSDictionary
*
)
dict
;
-
(
NSDictionary
*
)
modelToDictionary
;
@end
|
在测试用例中，我定义了一个testModelConvert方法用来测试模型跟json之间的转换是否正确：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
-
(
void
)
testModelConvert
{
NSString
*
json
=
@"{\"name\":\"SindriLin\",\"age\":22,\"flags\":987654321}"
;
NSMutableDictionary
*
dict
=
[
[
NSJSONSerialization
JSONObjectWithData
:
[
json
dataUsingEncoding
: NSUTF8StringEncoding
]
options
: kNilOptions
error
: nil
]
mutableCopy
]
;
LXDTestsModel
*
model
=
[
[
LXDTestsModel
alloc
]
initWithDictionary
: dict
]
;
XCTAssertNotNil
(
model
)
;
XCTAssertTrue
(
[
model
.
name
isEqualToString
:
@"SindriLin"
]
)
;
XCTAssertTrue
(
[
model
.
age
isEqual
:
@
(
22
)
]
)
;
XCTAssertEqual
(
model
.
flags
,
987654321
)
;
XCTAssertTrue
(
[
model
isKindOfClass
:
[
LXDTestsModel
class
]
]
)
;
model
=
[
LXDTestsModel
modelWithName
:
@"Tessie"
age
: dict
[
@"age"
]
flags
:
562525
]
;
XCTAssertNotNil
(
model
)
;
XCTAssertTrue
(
[
model
.
name
isEqualToString
:
@"Tessie"
]
)
;
XCTAssertTrue
(
[
model
.
age
isEqual
: dict
[
@"age"
]
]
)
;
XCTAssertEqual
(
model
.
flags
,
562525
)
;
NSDictionary
*
modelJSON
=
[
model
modelToDictionary
]
;
XCTAssertTrue
(
[
modelJSON
isEqual
: dict
]
==
NO
)
;
dict
[
@"name"
]
=
@"Tessie"
;
dict
[
@"flags"
]
=
@
(
562525
)
;
XCTAssertTrue
(
[
modelJSON
isEqual
: dict
]
)
;
}
|
逻辑测试的目的是为了检测在代码执行前后发生的变化是否符合预期，因此可以说80%左右的单元测试都是逻辑测试。最开始笔者学习单元测试的时候总有一种无从下手的感觉，但是当你从无形抽象的逻辑操作找到了数据变化的规律的时候，对应的单元测试就能很快的写出来了
性能测试
相较于上面的逻辑测试，性能测试的地位有些尴尬。在现今的开发环境下，我们已经能通过 instrument工具很好的查找到项目中的代码耗时点，性能测试就有种弃之可惜，食之无味的感觉了。但是为了本文的完整性，还是将这个补充完毕。笔者在测试model类中添加了类方法，用来随机生成100个类实例对象，并且在每次创建对象后让线程休眠一段时间来模拟耗时操作：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
+
(
NSArray
<
LXDTestsModel
*
>
*
)
randomModels
{
NSMutableArray
*
models
=
@
[
]
.
mutableCopy
;
NSArray
*
names
=
@
[
@"SindriLin"
,
@"Bison"
,
@"XiongZengHui"
,
@"ZengChengChun"
,
@"Tessie"
]
;
NSArray
*
ages
=
@
[
@
15
,
@
20
,
@
25
,
@
30
,
@
35
]
;
NSArray
*
flags
=
@
[
@
123
,
@
456
,
@
789
,
@
012
,
<
a
href
=
"http://www.jobbole.com/members/234"
>
@
234
<
/
a
>
]
;
for
(
NSUInteger
idx
=
0
;
idx
<
100
;
idx
++
)
{
LXDTestsModel
*
model
=
[
LXDTestsModel
modelWithName
: names
[
arc4random
(
)
%
names
.
count
]
age
: ages
[
arc4random
(
)
%
ages
.
count
]
flags
:
[
flags
[
arc4random
(
)
%
flags
.
count
]
unsignedIntegerValue
]
]
;
[
models
addObject
: model
]
;
[
NSThread
sleepForTimeInterval
:
0.01
]
;
}
return
models
;
}
|
运行测试用法后控制台会输出下面的信息，其中红框中表示执行代码总耗时，在此demo中总共运行了11.015秒的时长
虽然性能测试的定位确实有些鸡肋，但是另一方面，直接使用单元测试来获取某段代码的执行时间要比使用instrument快的多。通过性能测试直观的获取执行时间后，我们可以根据需要来决定是否将这些代码放到子线程中执行来优化代码（很多时候，数据转换会占用大量的CPU计算资源）
异步测试
由于单元测试是在主线程中进行的，因此异步操作的测试在执行完毕之前，往往已经结束了。为了实现异步测试，笔者采用while()的方式无限循环等待，为了实现这个效果，我在LXDTestsModel头文件中添加了一个NSData类型的属性以及一个异步操作的接口方法，通过判断这个属性值来实现效果：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
-
(
void
)
asyncConvertToData
{
dispatch_async
(
dispatch_get_global_queue
(
DISPATCH_QUEUE_PRIORITY_DEFAULT
,
0
)
,
^
{
NSDictionary
*
modelJSON
=
nil
;
for
(
NSInteger
idx
=
0
;
idx
<
20
;
idx
++
)
{
modelJSON
=
[
self
modelToDictionary
]
;
[
self
setValuesWithDictionary
: modelJSON
]
;
[
NSThread
sleepForTimeInterval
:
0.001
]
;
}
_data
=
[
NSJSONSerialization
dataWithJSONObject
: modelJSON
options
: NSJSONWritingPrettyPrinted
error
: nil
]
;
}
)
;
}
|
上面的代码在系统创建的默认等级的子线程中执行了一段耗时代码，最后把json转换成NSData数据保存在自身的属性中。对应的异步测试代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
-
(
void
)
testAsync
{
NSDictionary
*
dict
=
@
{
@"name"
:
@"SindriLin"
,
@"age"
:
@
22
,
@"flags"
:
@
987654321
}
;
LXDTestsModel
*
model
=
[
[
LXDTestsModel
alloc
]
initWithDictionary
: dict
]
;
XCTAssertNotNil
(
model
)
;
[
model
asyncConvertToData
]
;
while
(
model
.
data
==
nil
)
{
CFRunLoopRunInMode
(
kCFRunLoopDefaultMode
,
0.01
,
YES
)
;
NSLog
(
@"waiting"
)
;
}
XCTAssertNotNil
(
model
.
data
)
;
NSLog
(
@"convert finish %@"
,
model
.
data
)
;
}
|
同样的，如果你的异步操作是网络请求，那么在执行的回调外对获取的数据类型加上__block修饰，然后判断这个获取的数据是否不为空来停止循环。另外最重要的是你必须在你的死循环中加入CFRunLoopRunInModel这个函数的调用来保证即便是在等待的情况下，你的主线程仍然能处理其他的事情。
|
1
2
3
4
5
6
7
8
9
10
11
|
__block
BOOL
complete
=
NO
;
__block
NSData
*
data
=
nil
;
[
network
POST
:
@"http://xxxxxxx"
parameters
: nil
completion
:
^
(
NSData
*
receiveData
)
{
data
=
receiveData
;
complete
=
YES
:
}
]
;
while
(
!
complete
)
{
CFRunLoopRunInMode
(
kCFRunLoopDefaultMode
,
0.01
,
YES
)
;
NSLog
(
@"requesting"
)
;
}
|
尾言
最开始笔者一度认为单元测试是个比较考验技术的东西，但恰恰相反的，单元测试的使用与概念是相当简单的一个东西，难点在于不知道怎么用，这就需要我们持续的使用练习才能更好的服务于我们的开发。此外，常用的第三方框架例如YYModel、AFNetworking、Alamofire等等优秀框架中也有对框架自身编写的单元测试，学习仿写这些单元测试也是快速提升自己的一种手段。
很多时候，我们的项目中难免发生多个类之间的交互处理，而这种操作非常的不好调试。单元测试的原则之一就在于我们用来测试的代码要求功能很单一，这其实与良好的代码设计的思想是非常相符的。一方面来说，良好的代码结构设计可以让我们的测试用例的构建更加快速简单；反过来单元测试逼着我们去想办法减少类之间的耦合以此来减少甚至排除测试的干扰。无论如何，如果你想成为更好的开发者，单元测试是我们快速提升代码认知的重要手段之一。
原文：http://ios.jobbole.com/85560/?utm_source=blog.jobbole.com&utm_medium=relatedPosts
扫一扫
1674
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
