ios测试-(一)使用XCTest进行单元测试 秒速五厘米 2022-08-27 10:56 488阅读 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
还没有评论,来说两句吧...