ios测试-（一）使用XCTest进行单元测试

秒速五厘米 2022-08-27 10:56 527阅读 0赞

在Objc.io \#1的[Testing View Controllers][]中讲解的就是单元测试的相关内容。本文说下如何通过Xcode 5中集成的XCTest框架进行简单的单元测试。

# 什么是单元测试 #

首先什么是单元测试？[维基百科][Link 1]中的解释是：

在计算机编程中，单元测试（又称为模块测试, Unit Testing）是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

通常来说，程序员每修改一次程序就会进行最少一次单元测试，在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书（en:Specification）要求的工作目标，没有程序错误；虽然单元测试不是什么必须的，但也不坏，这牵涉到项目管理的政策决定。

由于我们OC程序员写的通常都是面向对象的程序，所以我们在进行单元测试时，通常都是以一个方法为单位测试，目的当然是保证其不会出错了。按照Objc.io文章的观点，如果我们代码之间的耦合度很小，那么可以将其分解成多个小部件，从而更易于测试。

原文还提到一个概念：TDD(Test-Driven Development)，即测试驱动开发，该模式要求开发者在编写某个功能的代码之前先将其测试代码写好，然后编写实现代码并进行测试，从而保证实现的代码不会出现问题。因此整个项目的开发进度将由测试来驱动，这有助于开发出高质量而又正确的代码，实现敏捷开发。（Objc.io上面的文章真的非常的好）

好吧，科普完了，下面进入Xcode Unit Testing的部分。

# XCTest #

## 1.第一个单元测试 ##

XCTest是Xcode 5中自带的测试框架，它和Xcode 4及之前的SenTestKit，OCUnit有什么前因后果，小弟没有做多少研究，所以不说了。

下面从一个Demo开始。首先用Xcode新建一个工程UnitTestDemo，工程目录结构如下：

![20140319203720625][]

可以看到工程下面多了一个叫UnitTestDemoTests的部分，Targets也多了一个UnitTestDemoTests，根据图标初步认为该Target跑的是一个框架。

这两个多出来的东西（相比Xcode 4没有Include Unit Tests的工程）就是用来做单元测试的，其特点是文件名或Target名都以Tests结尾。

再来看下UnitTestDemoTests.m中的代码：

**\[objc\]** [view plain][] [copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  \#import <XCTest/XCTest.h>
2.  
3.  **@interface** UnitTestDemoTests : XCTestCase 
4.  
5.  **@end**
6.  
7.  **@implementation** UnitTestDemoTests 
8.  
9.  \- (**void**)setUp 
10. \{ 
11.  \[**super** setUp\]; 
12. // Put setup code here. This method is called before the invocation of each test method in the class.
13. \} 
14. 
15. \- (**void**)tearDown 
16. \{ 
17. // Put teardown code here. This method is called after the invocation of each test method in the class.
18.  \[**super** tearDown\]; 
19. \} 
20. 
21. \- (**void**)testExample 
22. \{ 
23.  XCTFail(@"No implementation for \\"%s\\"", \_\_PRETTY\_FUNCTION\_\_); 
24. \} 
25. 
26. **@end**

该类继承自XCTestCase类，其中包含 三个方法：setUp，tearDown和testExample。

setUp方法用于在测试前设置好要测试的方法，tearDown则是在测试后将设置好的要测试的方法拆卸掉。

testExample顾名思义就是一个示例。

按快捷键Command + U进行单元测试，结果如下：

![20140319205130390][]

可以看到没有通过测试，在Issue Navigator和控制台都输出了错误信息：本类中的testExample方法没有实现。

实际上，这个错误是我们主动抛出来的。XCTFail是一个宏，其作用就是让测试失败，后面的No implementation for \\"%s\\"", \_\_PRETTY\_FUNCTION\_\_就是要报告的错误信息，由我们自定。

报错总是让人不爽，好吧，我们将其注释掉，另外写一个测试方法，尝点甜头。为了规范，建议每个测试方法都写成“ - (void)testXXX ”形式，XXX表示要测试的方法名，并且无返回类型。

**\[objc\]** [view plain][] [copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  //- (void)testExample
2.  //\{ 
3.  // XCTFail(@"No implementation for \\"%s\\"", \_\_PRETTY\_FUNCTION\_\_);
4.  //\}
5.  
6.  \- (**void**)testTrue \{ 
7.   XCTAssert(1, @"Can not be zero"); 
8.  \}

Command + U，搞定：

![20140319210701281][]

注意左边的Test Navigator，绿色的标志表示测试全部通过。

## 2.测试的顺序 ##

如果在同一测试类文件中多写几个方法，例如：

**\[objc\]** [view plain][] [copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  \- (**void**)testTrue2 \{ 
2.   NSLog(@"2222222222222222222222"); 
3.   XCTAssert(1, @"Can not be zero"); 
4.  \} 
5.  
6.  \- (**void**)testTrue1 \{ 
7.   NSLog(@"1111111111111111111111"); 
8.   XCTAssert(1, @"Can not be zero"); 
9.  \} 
10. 
11. \- (**void**)testTrue3 \{ 
12.  NSLog(@"3333333333333333333333"); 
13.  XCTAssert(1, @"Can not be zero"); 
14. \} 
15. 
16. \- (**void**)testAtrue \{ 
17.  NSLog(@"0000000000000000000000"); 
18.  XCTAssert(1, @"Can not be zero"); 
19. \}

控制台部分输出：

**\[plain\]** [view plain][] [copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  Test Case '-\[UnitTestDemoTests testAtrue\]' started. 
2.  2014-03-19 21:19:38.182 UnitTestDemo\[7401:60b\] 0000000000000000000000 
3.  Test Case '-\[UnitTestDemoTests testAtrue\]' passed (0.001 seconds). 
4.  Test Case '-\[UnitTestDemoTests testTrue1\]' started. 
5.  2014-03-19 21:19:38.183 UnitTestDemo\[7401:60b\] 1111111111111111111111 
6.  Test Case '-\[UnitTestDemoTests testTrue1\]' passed (0.000 seconds). 
7.  Test Case '-\[UnitTestDemoTests testTrue2\]' started. 
8.  2014-03-19 21:19:38.184 UnitTestDemo\[7401:60b\] 2222222222222222222222 
9.  Test Case '-\[UnitTestDemoTests testTrue2\]' passed (0.013 seconds). 
10. Test Case '-\[UnitTestDemoTests testTrue3\]' started. 
11. 2014-03-19 21:19:38.196 UnitTestDemo\[7401:60b\] 3333333333333333333333 
12. Test Case '-\[UnitTestDemoTests testTrue3\]' passed (0.001 seconds).

可以看到无论我们怎样调换test方法的书写顺序，其测试顺序都是不变的。

目前初步的结论：测试方法执行的顺序与方法名中test后面的字符大小有关，小者优先，例如testA，testB1，testB2三个方法相继执行。

## 3.断言测试 ##

下面一共18个断言（SDK中也是18个，其含义转自[ios UnitTest 学习笔记][ios UnitTest]，真心佩服原文的博主，部分宏小弟已经测试过）：

XCTFail(format…) 生成一个失败的测试；

XCTAssertNil(a1, format...)为空判断，a1为空时通过，反之不通过；

XCTAssertNotNil(a1, format…)不为空判断，a1不为空时通过，反之不通过；

XCTAssert(expression, format...)当expression求值为TRUE时通过；

XCTAssertTrue(expression, format...)当expression求值为TRUE时通过；

XCTAssertFalse(expression, format...)当expression求值为False时通过；

XCTAssertEqualObjects(a1, a2, format...)判断相等，\[a1 isEqual:a2\]值为TRUE时通过，其中一个不为空时，不通过；

XCTAssertNotEqualObjects(a1, a2, format...)判断不等，\[a1 isEqual:a2\]值为False时通过；

XCTAssertEqual(a1, a2, format...)判断相等（当a1和a2是 C语言标量、结构体或联合体时使用,实际测试发现NSString也可以）；

XCTAssertNotEqual(a1, a2, format...)判断不等（当a1和a2是 C语言标量、结构体或联合体时使用）；

XCTAssertEqualWithAccuracy(a1, a2, accuracy, format...)判断相等，（double或float类型）提供一个误差范围，当在误差范围（+/-accuracy）以内相等时通过测试；

XCTAssertNotEqualWithAccuracy(a1, a2, accuracy, format...) 判断不等，（double或float类型）提供一个误差范围，当在误差范围以内不等时通过测试；

XCTAssertThrows(expression, format...)异常测试，当expression发生异常时通过；反之不通过；（很变态） XCTAssertThrowsSpecific(expression, specificException, format...) 异常测试，当expression发生specificException异常时通过；反之发生其他异常或不发生异常均不通过；

XCTAssertThrowsSpecificNamed(expression, specificException, exception\_name, format...)异常测试，当expression发生具体异常、具体异常名称的异常时通过测试，反之不通过；

XCTAssertNoThrow(expression, format…)异常测试，当expression没有发生异常时通过测试；

XCTAssertNoThrowSpecific(expression, specificException, format...)异常测试，当expression没有发生具体异常、具体异常名称的异常时通过测试，反之不通过；

XCTAssertNoThrowSpecificNamed(expression, specificException, exception\_name, format...)异常测试，当expression没有发生具体异常、具体异常名称的异常时通过测试，反之不通过

特别注意下XCTAssertEqualObjects和XCTAssertEqual。

XCTAssertEqualObjects(a1, a2, format...)的判断条件是\[a1 isEqual:a2\]是否返回一个YES。

XCTAssertEqual(a1, a2, format...)的判断条件是a1 == a2是否返回一个YES。

对于后者，如果a1和a2都是基本数据类型变量，那么只有a1 == a2才会返回YES。例如下面代码中只有第二行可以通过测试：

**\[objc\]** [view plain][] [copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  // 1.比较基本数据类型变量
2.  XCTAssertEqual(1, 2, @"a1 = a2 shoud be true"); // 无法通过测试
3.  XCTAssertEqual(1, 1, @"a1 = a2 shoud be true"); // 通过测试

但是，如果a1和a2都是指针，那么只有a1和a2指向同一个对象才会返回YES。例如下面的代码中：

**\[objc\]** [view plain][] [copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  // 3.比较NSArray对象
2.  **NSArray** \*array1 = @\[**@1**\]; 
3.  **NSArray** \*array2 = @\[**@1**\]; 
4.  **NSArray** \*array3 = array1; 
5.  XCTAssertEqual(array1, array2, @"a1 and a2 should point to the same object"); // 无法通过测试
6.  XCTAssertEqual(array1, array3, @"a1 and a2 should point to the same object"); // 通过测试

array1和array2指向不同对象，无法通过测试。

这里比较奇怪的是，NSString另当别论：

**\[objc\]** [view plain][] [copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  // 2.比较NSString对象
2.  **NSString** \*str1 = @"1"; 
3.  **NSString** \*str2 = @"1"; 
4.  **NSString** \*str3 = str1; 
5.  XCTAssertEqual(str1, str2, @"a1 and a2 should point to the same object"); // 通过测试
6.  XCTAssertEqual(str1, str3, @"a1 and a2 should point to the same object"); // 通过测试

尽管str1和str2指向不同的对象，但是二者的指针比较却能通过测试。不知道这是不是XCTest框架本身的一个Bug，反正在这里使用NSString要小心就是了。

由于str1和str2指向同一常量，常量在内存的data段中地址是固定的，所以二者地址相同。

掌握了各个断言的含义，用起来就没什么大问题了。

## 4.简单的应用 ##

说了一大堆理论和定义，下面来点实际的应用。下面有一个表格控制器：

**\[objc\]** [view plain][] [copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  \#import "TableViewController.h"
2.  \#import "TableDataSource.h"
3.  
4.  **static****NSString** \* **const** kCellIdentifier = @"Cell"; 
5.  
6.  **@interface** TableViewController () 
7.  
8.  **@property** (**strong**, **nonatomic**) **TableDataSource** \*dataSource; 
9.  
10. **@end**
11. 
12. **@implementation** TableViewController 
13. **@synthesize** dataSource = \_dataSource; 
14. 
15. \- (**void**)viewDidLoad 
16. \{ 
17.  \[**super** viewDidLoad\]; 
18. 
19.  TableViewCellConfigureBlock cellConfigureBlock = ^(**UITableViewCell** \*cell, **NSString** \*item) \{ 
20.  cell.textLabel.text = item; 
21.  \}; 
22. 
23. **NSArray** \*stringsArray = @\[@"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3", @"1", @"2", @"3"\]; 
24. **self**.dataSource = \[\[TableDataSource alloc\] initWithItems:stringsArray 
25.  CellIdentifier:kCellIdentifier 
26.  ConfigureCellBlock:cellConfigureBlock\]; 
27. 
28. **self**.tableView.dataSource = \_dataSource; 
29. \} 
30. 
31. **@end**

该类的UITableViewDataSource委托由一个TableDataSource类实现（将UITableViewDataSource分离，见Objc.io \#1[Lighter View Controllers][]）。TableDataSource类的初始化方法如下：

**\[objc\]** [view plain][] [copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  \- (instancetype)initWithItems:(**NSArray** \*)anItems 
2.   CellIdentifier:(**NSString** \*)aCellIdentifier 
3.   ConfigureCellBlock:(TableViewCellConfigureBlock)aConfigureCellBlock 
4.  \{ 
5.  **self** = \[**super** init\]; 
6.  
7.  **if** (**self**) \{ 
8.  **self**.items = anItems; 
9.  **self**.cellIdentifier = aCellIdentifier; 
10. **self**.configureCellBlock = \[aConfigureCellBlock copy\]; 
11.  \} 
12. 
13. **return****self**; 
14. \}

下面写一个Tests类测试一下DataSource的初始化方法。首先新建一个test case class类：

![20140319223032656][]

继承自XCTestCase类：

![20140319223217671][]

为了规范，我们新建的测试类都应该以Tests结尾，例如CellConfigureTests。

然后写个testDataSourceInitializing方法：

**\[objc\]** [view plain][] [copy][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  \- (**void**)testDataSourceInitializing \{ 
2.   TableViewCellConfigureBlock cellConfigureBlock = ^(**UITableViewCell** \*cell, **NSString** \*item) \{ 
3.   cell.textLabel.text = item; 
4.   \}; 
5.  
6.  **TableDataSource** \*tableSource = \[\[TableDataSource alloc\] initWithItems:@\[@"1", @"2", @"3"\] 
7.   CellIdentifier:@"TestCell"
8.   ConfigureCellBlock:cellConfigureBlock\]; 
9.  
10.  XCTAssertNotNil(tableSource, @"TableView data source should not be nil"); 
11. \}

Command + U运行测试。如果TableDataSource初始化成功，那么tableSource将不会为nil，测试就能通过。

Demo下载地址：[点此进入下载页][Link 2]

本文先说到这里，[下一篇博客][Link 3]说下如何借助更加强大的OCMock和GHUnit进行单元测试。

参考资料：

[iOS7初体验(2)——单元测试][iOS7_2]

[ios UnitTest 学习笔记][ios UnitTest]

[XCode下的iOS单元测试][XCode_iOS]

[Lighter View Controllers][]

[Testing View Controllers][]

[单元测试][Link 1]

[Testing View Controllers]: http://www.objc.io/issue-1/testing-view-controllers.html
[Link 1]: http://zh.wikipedia.org/wiki/%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95
[20140319203720625]: /images/20220824/75187e3776c146b6bdd067fc4bd87527.png
[view plain]: http://blog.csdn.net/jymn_chen/article/details/21552941#
[CODE]: https://code.csdn.net/assets/CODE_ico.png
[CODE_CODE]: https://code.csdn.net/snippets/246549
[ico_fork.svg]: https://code.csdn.net/assets/ico_fork.svg
[ico_fork.svg 1]: https://code.csdn.net/snippets/246549/fork
[20140319205130390]: /images/20220824/43f1dc0d6efb4e72a30f0a5270c39811.png
[20140319210701281]: /images/20220824/0fbe2fff3f644b3da97ed82078548589.png
[ios UnitTest]: http://www.cnblogs.com/dokaygang128/p/3520761.html
[Lighter View Controllers]: http://www.objc.io/issue-1/lighter-view-controllers.html
[20140319223032656]: /images/20220824/6e48caa0daea45d18e3aeb93155c8100.png
[20140319223217671]: /images/20220824/9b06e26a0d404d2fa87580d939dc352e.png
[Link 2]: http://download.csdn.net/download/u010962810/7071019
[Link 3]: http://blog.csdn.net/u010962810/article/details/21562869
[iOS7_2]: http://www.cnblogs.com/liufan9/archive/2013/06/14/3135414.html
[XCode_iOS]: http://www.uml.org.cn/mobiledev/201201093.asp