[iOS翻译]《iOS7 by Tutorials》系列:在Xcode 5里使用单元测试(上)
简介:
单元测试是软件开发的一个重要方面。毕竟,单元测试可以帮你找到bug和崩溃原因,而程序崩溃是Apple在审查时拒绝app上架的首要原因。
单元测试不是万能的,但Apple把它作为开发工具包的一部分,不仅让你创作的APP更稳定,而且提供了一致、有趣的用户体验,这些都是让用户给你五星评价的源泉!iOS7提供了一个升级的单元测试框架,让你在Xcode中运行单元测试更为容易。当你完成这一章节,你将学会如何给现有app添加测试——并有可能培养出对编写测试的热爱!
/*
本文翻译自《iOS7 by Tutorials》一书的第十一章“Unit Testing in Xcode 5”,想体会原文精髓的朋友请到Raywenderlich商店支持正版。
——————(博客园、新浪微博)葛布林大帝
*/
目录:
一、单元测试基础
二、开始项目
三、下一步何去何从?
四、挑战
附录:XCTest断言参考
一、单元测试基础
在过去,Xcode引入了一个叫做OCUnit的开源单元测试框架。而在Xcode 5里面,Apple发布了他们自己的的单元测试框架,叫做XCTest。
如果你已经熟悉OCUnit,别担心,XCTest是一个建立在OCUnit之上并且十份相似的API。从OCUnit过渡到XCTest非常简单,要做的仅仅是把STFail替换为XCTFail、STAssert替换为XCTAssert等等诸如此类。如果你已经熟悉这些基础,可以直接跳到下一节。
1.高层次概述
单元测试有四个层级。从上到下,它们分别是:
- 测试套件(Test suite)
- 这是项目里测试的全部集合。在Xcode里,测试套件被设置为一个单独的build target。
- 测试用例类(Test case classes)
- 正如你可能所期待的,在一个面向对象体系中,测试被整合到类里。在你的app里,每个测试类通常对应一个单独类。例如,DeveloperTests类应该对应Developer类的测试。
- 测试用例方法(Test case methods)
- 每个测试类包含多种方法,用来测试类的各种功能。就像一个方法或函数应该既精简又实用,每个测试用例应该测试一个特定的结果——并且完全测试。
- 断言(Assertions)
- 断言检查对应预期结果的具体条件。如果条件不符合预期结果, Xcode会报错指出断言失败。例如,可以断言你的Developer 类响应“writeKillerApp: message”;如果它没有,断言失败,Xcode报错。
理论很美好,但有时举例会更容易阐述事物。用Empty Application 模板创建一个新项目,命名为EmptyApp。 Xcode模板会自动包含一个叫做EmptyAppTests的test target,添加到EmptyApp的 app target里,如下图:
注意测试用例类包含了一个没有关联头文件的.m文件,打开EmptyAppTests.m看看第一个测试用例的源代码。
测试方法必须以单词test开始,以便test runner能找到它们。在你的示例项目里,测试类包含了一个测试方法,叫做testExample。
setUp和tearDown方法就像守护在测试用例周围的卫兵一样。
把所有对象的程序设置代码或重复性代码放到setUp里,使测试用例方法保持清爽、高效。
类似的,关闭文件句柄或取消挂起网络请求等清理活动的方法应该放到tearDown里。
Test runner 会依次调用setUp、testExample和tearDown方法。如果你申明了第二个测试方法testSecondExample,Test runner会依次调用setUp、testSecondExample,最后是tearDown方法。如果你有多个测试方法,setUp和tearDown会在一个测试环节调用多次——每经过一个测试用例方法调用一次!
这个故事的寓意是不要放任何处理太慢或处理频繁的东西到setUp或tearDown方法里——这会让你运行测试套件时面临漫长的等待!
2.创建你的第一个测试
testExample方法只有一个叫做XCTFail的语句,正如它名字里暗示的:总是会失败。这个语句不是非常有用,你可以写一个比它更好的!删除testExample方法,并添加如下方法:
- (void)test_addition_twoPlusTwo_isFour
{
XCTAssert(2 + 2 == 4, @"2 + 2 should be 4 but %d was returned instead", 2+2);
}
测试用例的一个常用命名标准是:unitOfWork_stateUnderTest_expectedBehavior (工作单元_测试状态_预期行为)。
在这个例子里,被测试的工作单元是加法,测试状态是2 + 2,预期行为是结果为4。
所有XCTest断言都有前缀XCT。XCTAssert是可用于单元测试的简单断言,第一个参数是预评估为ture的表达式,当断言失败时,其后NSLog风格的参数会显示一条消息。
确保项目的当前target为iPhone模拟器,通过窗口顶部目录的Product -> Test(Command-U)来运行测试,模拟器会启动并执行测试套件。如果通知处于激活状态,你会看到下列确认消息:
为了证实第一个单元测试成功,切换到Test Navigator,箭头指出了它:
哈哈!翠绿色的小勾旁边显示出了你的单元测试。
你还可以看到边框空白处菱形图标旁的代码,如下所示:
这些图标展示关联测试代码的状态:
@implementation旁的绿色小勾表示这个类测试通过,test_addition_twoPlusTwo_isFour旁的绿色小勾表示这个方法测试通过。
同时,这些图标也是按钮:
点击@implementation旁的图标将会运行这个类的所有测试,点击其他测试方法旁的图标则会运行该测试方法,试一试吧!
现在你已经对测试的概念和执行有了初步了解,是时候开始本章的示例项目了——测试开始!
二、开始项目
本章的剩余部分你将使用一个名为Reversi的黑白棋游戏项目,规则:两个玩家,分别代表白方和黑方,轮流在8x8棋盘上落子。通过包围对方棋子来吃掉它,游戏结束时棋子最多的为胜者。
如何创建这个游戏,请看: http://www.raywenderlich.com/29228/how-to-develop-an-ipad-board-game-app-part-12
下载本文页尾提供的示例项目并运行,点击屏幕下方的Vs Computer按钮与电脑进行对战,感受一下这个游戏的界面和玩法。
你获胜了吗?或者被AI对手爆出翔?不管怎样,你的工作不是整日玩游戏——是时候添加一些有用的测试到项目里了。
1.添加测试的支持
第一个需要单元测试的是GameBoard类。这个类囊括了8x8棋盘的基本逻辑,64个单元格中的每个都有一个状态——空、黑棋或白棋——并且GameBoard实例让你能获取并设置每一个方块的状态。
打开GameBoard.h看一下里面的方法,在开始为现有代码编写测试之前,弄清楚各方法的作用和实现是一个好主意。
在GameBoard.h,你会看到下列两个方法:
// gets the state of the cell at the given location
// raises an NSRangeException if the column or row are out of bounds
- (BoardCellState) cellStateAtColumn:(NSInteger)column andRow:(NSInteger)row;
// sets the state of the cell at the given location
// raises an NSRangeException if the column or row are out of bounds
- (void) setCellState:(BoardCellState)state forColumn:(NSInteger)column andRow:(NSInteger)row;
cellStateAtColumn:andRow: 和 setCellState:forColumn:andRow: 由你非常熟悉的getter/setter模式里发展出来,你的第一个测试是执行如下动作:
- 初始化一个GameBoard实例
- 设置cell状态
- 获取cell状态
- 从指定的cell里获取cell状态
第一步是创建一个GameBoard测试类,右击ReversiGameTests分组,选择 iOS\Cocoa Touch\Objective-C test case class 创建一个名为GameBoardTests的测试类,继承自XCTestCase。
确保你的新测试用例添加到ReversiGameTests target,如下图(这个步骤非常重要,如果没添加到正确的target里,你的测试不会运行):
打开 GameBoardTests.m 并且删除 testExample 方法,你不需要它。
然后在 GameBoardTests.m 顶部导入头文件(这仅仅是让你的测试类能够访问GameBoard类):GameBoard.h
#import "GameBoard.h"
你需要为你的所有测试提供一个GameBoard 实例,创建一个实例变量会比在每个测试里申明一个清爽得多。
在GameBoardTests.m 里更新@interface 如下:
@interface GameBoardTests : XCTestCase
{
GameBoard *_board; }
现在你有了_board实例变量,可以开始测试了。
setUp 方法是第一次初始化_board的好地方,修改setUp如下:
- (void)setUp
{
[super setUp];
_board = [[GameBoard alloc] init];
}
现在这个类的所有测试用例方法都能够访问初始化后的_board实例变量了。
2.第一个测试
这是你需要为首个测试用例添加的所有步骤,添加以下方法到GameBoardTests.m:
- (void)test_setAndGetCellState_setValidCell_cellStateChanged
{
[_board setCellState:BoardCellStateWhitePiece forColumn:4 andRow:5];
BoardCellState retrievedState = [_board cellStateAtColumn:4 andRow:5];
XCTAssertEqual(BoardCellStateWhitePiece,
retrievedState,
@"The cell should be white!");
}
上面的代码在(4,5)单元格里设置了一个白棋,并且立刻检索了相同单元格的状态。XCTAssertEqual 断言检查它们是否相等,如果不相等,你会看到一个异常信息,然后你将得知有一些东西需要检查。
上面代码的方法名遵循我之前提到的格式,通过这个方法名,你可以很容易看出它通过设置正确的单元格位置来测试setter和getter方法,并期待单元格状态的改变。
如果你的测试工作是有计划的,确保iPhone和iPad模拟器都测试,然后运行测试(Command-U)。
切换到Test Navigator,你会看到一个绿色小勾表示测试通过,如下图:
这看起来只是一个简单的测试,但是它在调试错误里提供了巨大的价值。
在内部, GAMEBOARD类使用一个简单的二维数组来跟踪8X8棋盘。但如果你曾经改变了代表向量或矩阵的数组,本次测试将作为回归测试,确保interface 的基础仍在工作。
作为一个附带的好处,为现有的类编写测试可以大大有助于理解代码是如何工作的。分析类的方法可以帮助你辨别其功能,并为你编写测试提供便利。
3.测试异常
按照设计的功能测试代码有助于确保其正确性,但也使得你的app“早早失败或高调失败”——那些异常游戏状态或无效条件被调试器很快抓住。
GameBoard.h里cellStateAtColumn:andRow: 和 setCellState:forColumn:andRow: 方法的注释表明,如果行或列超出棋盘边框,它们会弹出错误。看起来你已经找到更多的测试条件。
添加下列两个方法:
- (void)test_setCellState_withInvalidCoords_exceptionThrown {
XCTAssertThrowsSpecificNamed(
[_board setCellState:BoardCellStateBlackPiece
forColumn:10
andRow:7], NSException,
NSRangeException,
@"Out-of-bounds board set should raise an exception");
}
- (void)test_getCellState_withInvalidCoords_exceptionThrown {
XCTAssertThrowsSpecificNamed(
[_board cellStateAtColumn:7 andRow:-10],
NSException,
NSRangeException,
@"Out-of-bounds board access should raise an exception");
}
上面的代码里,test_setCellState_withInvalidCoords_exceptionThrown: 试图设置超出范围的单元格(10,7),同时test_setCellState_withInvalidCoords_exceptionThrown: 试图获取超出范围的单元格(7,-10)。再次的,方法名已指出在正测试不正确的坐标,报出异常正在意料之中。
XCTAssertThrowsSpecificNamed 采用以下四点作为参数:
- 应该报出异常的表达式
- 排除的类
- 排除的名称
- 测试失败时显示的消息
点击Command-U运行测试,你应该看到以下结果
这是什么?你希望用出色的代码通过测试,但是两个错误标记在Issue Navigator上。测试失败信息也会显示在代码上,如下图:
所有的测试失败消息为:
[GameBoardTests test_getCellState_withInvalidCoords_exceptionThrown] failed: (([_board cellStateAtColumn:7 andRow:-10]) throws <NSException, "NSRangeException">) failed: throwing <NSException, "NSGenericException", "row or column out of bounds"> - Out-of- bounds board access should raise an exception
如果你分解上面的消息,你会看到你希望的行为是(throws <NSException, "NSRangeException">) ,而实际发生的是(throwing <NSException, "NSGenericException">) 。
在这个例子里,你期待的是NSRangeException ,但接收到的却是NSGenericException 。
看起来你已经做了一些研究!
示例项目地址: http://pan.baidu.com/s/1o6x6zxg