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:NSRangeExceptionformat:@"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:] + 1393 ReversiGame -[GameBoard checkBoundsForColumn:andRow:] + 142 4 ReversiGame -[GameBoard cellStateAtColumn:andRow:] + 765 ReversiGame -[ReversiBoard flipOpponentCountersForColumn: andRow:withNavigationFunction:toState:] + 2816 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-1Demystifying iOS Application Crash Logshttp://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...)表达式应该抛出一个异常信息；更详细的版本让你指出类名和异常名 XCTAssertNoThrowXCTAssertNoThrowSpecificXCTAssertNoThrowSpecificNamed如果异常被抛出，这些断言会失败

iOS7单元测试下