4.测试失败的调试
是时候追踪之前测试失败的问题了。打开GameBoard.m,找到cellStateAtColumn:andRow: 和 setCellState:forColumn:andRow: 方法,你会看到它们都调用了一个叫做checkBoundsForColumn:andRow: 的helper方法,用来检测数组边界。
头文件 GameBoard.h 里的方法注释如下:
// raises an NSRangeException if the column or row are out of bounds
然而,如果超出边界,checkBoundsForColumn:andRow: 方法的实现抛出了一个NSGenericExpression 。通常的,你把头文件里的注释当做一个公共API规范,但在这个例子里代码和规范并不匹配,你该如何做?
一个可能性是更新注释和相关的测试,以匹配当前的实现。在这个例子里,规范里的注释看起来更有意义:一个边界检查应当遵循NSArray,并升起一个NSRangeException。
在GameBoard.m里,更新checkBoundsForColumn:andRow: 方法的实现如下:
- (void)checkBoundsForColumn:(NSInteger)column andRow:(NSInteger)row
{
if (column < 0 || column > 7 || row < 0 || row > 7)
[NSException raise:NSRangeException
format:@"row or column out of bounds"];
}
重新运行测试,这时所有测试应该能够通过了。
自从代码不同步,注释里的规范总是有一点危险。然而,你的测试可以为注释添加双保险。自从你编写测试代码后,只要你经常运行测试,这些实现不匹配的风险会大大减小!
另外,你的测试提供了一个伟大的高层概览代码,特别是遵循建议的命名规范以后。当你重新进入很久没碰过的代码后,这会非常方便——正如下一小节的内容。
5.保证测试bug
一个崩溃报告刚刚进入你的app:你的一个测试人员报告你,当她运行游戏后直接点击屏幕(不点击"2 Player"或者"vs computer"按钮),程序就会崩溃。
你自己试一遍,就会在控制台看到下列信息:
ReversiGame[1842:a0b] *** Terminating app due to uncaught exception 'NSRangeException', reason: 'row or column out of bounds'
崩溃看起来重复发生,是什么抛出了一个NSRangeException ?call stack提供了以下信息:
2 CoreFoundation +[NSException raise:format:] + 139
3 ReversiGame -[GameBoard checkBoundsForColumn:andRow:] + 142 4 ReversiGame -[GameBoard cellStateAtColumn:andRow:] + 76
5 ReversiGame -[ReversiBoard flipOpponentCountersForColumn: andRow:withNavigationFunction:toState:] + 281
6 ReversiGame -[ReversiBoard makeMoveToColumn:andRow:] + 245 7 ReversiGame -[BoardSquare cellTapped:] + 192
从下往上读:
第7、6行 tap触发代码用来处理玩家的移动
第5行 游戏逻辑检查是否有对手的棋子被包围并且翻转
第4、3行 代码然后调用cellStateAtColumn:andRow: 和
checkBoundsForColumn:andRow:
第2行 底层框架报出一个越界异常
想了解更多调试崩溃的信息?看这里
My App Crashed, Now What?
http://www.raywenderlich.com/10209/my-app-crashed-now-what-part-1
Demystifying iOS Application Crash Logs
http://www.raywenderlich.com/23704/demystifying-ios-application-crash-logs
这是一个测试这些崩溃条件的绝好机会。
你的新测试不止要修复这个问题,而且要作为一个回归测试确保这个bug保持修复。没有什么比修复一个bug后,数月之后添加新功能或重构代码时再遇到相同的bug更让人不爽的了。
6.决定什么需要测试
你知道你需要测试——但应该测试什么?
ReversiBoard 是GameBoard类的通用实现,所以从这里开始故障排除工作是有意义的。
使用iOS\Cocoa Touch\Objective-C test case class 模板创建一个新类,命名为ReversiBoardTests, 继承自XCtestCase。
在开始之前,删除模板文件的testExample方法,然后在ReversiBoardsTests.m 里导入头文件:
#import "ReversiBoard.h"
在ReversiBoardsTests.m 里改变@interface 如下:
@interface ReversiBoardTests : XCTestCase { ReversiBoard *_reversiBoard;
}
添加一个_reversiBoard 实例变量意味着你不用在每个测试方法里反复实例化。
然后修改setUp方法如下:
- (void)setUp {
[super setUp];
_reversiBoard = [[ReversiBoard alloc] init];
}
7.测试否定
在之前的编写的测试中,异常的存在是预期的结果。这一次,异常并没有在你的测试基础上出现。
添加这些方法到ReversiBoardsTests.m

- (void)test_makeMove_inPreGameState_nothingHappens {
[_reversiBoard setToPreGameState];
XCTAssertNoThrowSpecificNamed(
[_reversiBoard makeMoveToColumn:3 andRow:3],
NSException,
NSRangeException,
@"Making a move in the pre-game state should do nothing");
}
上面的代码中,测试设置游戏前的状态。也就是说,玩家作出对战AI还是对战其他玩家选择之前的状态。这个测试模拟了一进入游戏就点击棋盘的动作。
XCTAssertNoThrowSpecificNamed 断言与XCTAssertThrowsSpecificNamed 刚好相反。如果指定的异常被抛出,上面的测试会失败;如果指定的异常没被抛出,测试会通过。
你还没有修复bug,所以现在运行代码将会失败——不过这是件好事,在修复bug之前编写测试意味着你拥有重现bug的测试能力。
Command+U 运行测试,你会看到如下信息:
test failure: -[ReversiBoardTests test_makeMove_inPreGameState_nothingHappens] failed: (([_reversiBoard makeMoveToColumn:3 andRow:3]) does not throw <NSException, "NSRangeException">) failed
8.校正代码
打开 ReversiBoard.m 然后找到 makeMoveToColumn:andRow: 方法。
思考一下如何修正这个特定的bug。只有用户选择了游戏模式之后才可以移动,这是很有意义的。这样一想,游戏前和游戏后的游戏逻辑没有什么不同。
幸运的是,这里有一个属性指定当前的游戏状态:gameState.
添加以下代码到makeMoveToColumn:andRow: 方法的顶部:
if ([self gameState] != GameStateOn) return;
这个条件检测了当前的游戏状态。如果状态不是GameStateOn——说明游戏不在运行中——方法立即终止。
运行app,测试一下在选择游戏模式之前点击棋盘,是否崩溃?
最后,Command+U 运行测试,Test Navigator应该显示绿色小勾,bug被碾碎了!
探索风格的测试只用包含明显问题的代码,然而回归风格的测试则可以为经常修复某个问题提供了保障。
修复每个bug不止是让你的代码更健康,同时让你有更多时间思考你的单元测试。
三、下一步何去何从?
测试是开发生涯的一个巨大任务,这章我们掌握了单元测试的基础,下面是一些有益的概念:
- 使用哪一个断言?在哪里使用断言?
- 添加测试到一个现有app
- 在程序说明里使用测试
- 探寻并修复bug
- 确保已经修复过的bug不再出现
Xcode中整合的XCTest让建立测试套件非常容易,整个iOS领域的测试范围是非常广大的,更多测试概念:
- Mock objects
- 在测试里模拟出足够真实的对象
- http://ocmock.org/
- 在测试里模拟出足够真实的对象
- UI testing
- 可以模拟出用户的输入,比如touch或文本输入。
- Continuous integration (CI) systems
- 将会自动运行单元测试,想了解更多关于CI的功能,阅读本书14、15章“Beginning and Intermediate Continuous Integration in Xcode 5
在深度学习测试之前,这里有几个挑战来让你掌握本章的概念。
四、挑战
GameBoard 类仍然还有一些方法没被测试——你的任务是编写测试,为你的app提供一个完整的测试套件。
1.挑战一:测试 clearBoard
clearBoard 清除棋盘上的所有棋子。自从已经测试getter和setter 方法后,你可以假设这些方法无需再次测试。
celarBoard的测试用例有以下几个步骤:
1)至少设置一个黑棋在棋盘上
2)至少设置一个白棋在棋盘上
3)调用clearBoard
4)检查你现在放置白棋和黑棋的地方是空的(提示:状态为BoardCellStateEmpty)
记住测试用例遵循的命名格式:工作单元或方法名、测试什么、预期的结果
2.挑战二:测试scorekeeper
countCellsWithState: 记录棋盘上特定状态棋子的数量。这个方法计算出最后的分数,所以确保它正确工作是非常必要的!
countCellsWithState: 的测试用例将执行以下动作:
1)设置一些黑棋或白棋在棋盘上
2)追踪棋子增加的数量
3)比较你的数量与countCellsWithState:返回的数量
countCellsWithState:有一个状态参数,所以它看起来像这样
[_board countCellsWithState:BoardCellStateWhitePiece]
再次,确定你的测试用例命名恰当
祝你测试成功!
附录:XCTest断言参考
下列所有断言都使用(format...)作为最后一个参数,这个NSlog风格的参数会在测试失败时显示消息。
XCTFail(format...) 无条件失败;用来标记不应执行的代码部分 XCTAssertNil(exp, format...) XCTAssertNotNil(exp, format...) 表达式应为nil或not nil;在OC对象中使用 XCTAssert(exp, format...) XCTAssertTrue(exp, format...) XCTAssertFalse(exp, format...) 表达式应为true或false XCTAssertEqualObjects(a1, a2, format...) OC对象a1和a2应该相等;使用isEqual: 来保持相等 XCTAssertEqual(a1, a2, format...) 参数a1和a2应该相等;用来比较C数量、集合及结构体(如CGRect和CGPoint);使用NSValue来比较 XCTAssertEqualWithAccuracy(a1, a2, delta, format...) 参数a1与参数a2应该与给定的delta值相等;使用float和double类型,其中小数值可能不够精确 XCTAssertThrows(exp, format...) XCTAssertThrowsSpecific(exp, exception, format...) XCTAssertThrowsSpecificNamed(exp,exception,exceptionName,format...) 表达式应该抛出一个异常信息;更详细的版本让你指出类名和异常名 XCTAssertNoThrow XCTAssertNoThrowSpecific XCTAssertNoThrowSpecificNamed 如果异常被抛出,这些断言会失败