今天刷完了Raywenderlich的Testing视频。了解了一下iOS中的单元测试。
为什么要单元测试
为什么要进行单元测试呢？Wiki里面是这样写的。
在计算机编程中，单元测试（又称为模块测试, Unit Testing）是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
通常来说，程式設計師每修改一次程式就會進行最少一次單元測試，在編寫程式的過程中前後很可能要進行多次單元測試，以證實程式達到軟件規格書要求的工作目標，沒有程序錯誤；雖然单元测试不是什么必须的，但也不坏，這牽涉到專案管理的政策決定。
每个理想的测试案例独立于其它案例；为测试时隔离模块，经常使用stubs、mock[1]或fake等测试马甲程序。单元测试通常由软件开发人员编写，用于确保他们所写的代码符合软件需求和遵循开发目标。它的實施方式可以是非常手動的（透過紙筆），或者是做成構建自動化的一部分。
测试流程
创建一个测试用的Target,测试代码会放在一个单独的Target中，用于与生产代码的隔离，但是同时又可以import。
在创建项目的时候在include Unit Test打上勾。
如果是旧的项目，而且在创建的时候没有打钩，不用担心，我们可以通过File->New->Target
创建一个iOS Unit Test Bundle
可以看到在右侧的导航栏里面多了一个xxxxTests的Group。
打开里面默认生成的文件
我们可以看到有一个叫UnitTestDemoTests的默认类，他们继承于XCTestCase,这个就是Apple为我们准备的测试框架，我们所有的测试用例的类都要继承于它。
再看代码的实现，发现有三个方法。
分别是
- (void)setUp;
- (void)tearDown;
- (void)testExample;
这里面setUp和tearDown是用创建现场和清理现场。而testExample则是一个示例测试方法，在每次执行测试方法之前都是执行setUp，执行完之后就会调用tearDown，所以这里有多少个被测试方法，setUp和tearDown就会被调用几次。所以在setUp方法里面进行一些下文都需要用到的对象初始化工作是很有帮助的。
都准备好了，接下来就是要写测试用例。这里最好保证每个测试的方法都是测试单一的功能。
Xcode为我们提供了很多的断言。都是以XCTAssert开头的方法,断言中的表达式为YES，则测试通过，否则测试不通过，会提示相应的错误。
这里我们来创建一个
- (void)testNumberIsZero {
NSInteger number = 0;
XCTAssertEqual(number, 0, @"the number is not zero");
}
一个非常简单的测试，用于测试被测数据是否为0，点击方法左边的按钮来运行单个测试方法。测试通过以后，会有一个绿的勾表示测试通过。
而如果发生错误的话则会是红色的叉，并且告诉你在哪里有错误。
什么时候测试
在我看来，单元测试应该是贯穿于整个开发之中，如果是采用测试驱动开发的话应该在先写测试用例，然后再进行程序的开发。而对于一般来说，在进行代码的重构之后，或者功能迭代之后，都需要跑一边测试，依赖检测新加的代码是否可靠，检测是否对其他的功能造成了影响，如果某个测试挂了，可以很快的定位到问题的所在。
代码覆盖率
在做单元测试时，代码覆盖率常常被拿来作为衡量测试好坏的指标。为什么在这里要提这个呢，原因就是Xcode7现在可以直接查看代码的覆盖率。不过需要自己手动开启一下，默认是关闭的。编辑Targe的scheme,如果所示，给gather coverage data打钩用于搜集覆盖率的数据,这样就可以了，Xcode会重新编译程序。
然后重新来跑一边测试
这里可以看到每个文件的代码覆盖率是多少，如果是100%说明这个文件里面的代码至少被测试过一遍。虽然代码覆盖率高是好事情，但是有时候用代码覆盖率来考核测试任务完成情况，规定代码覆盖率必须达到80％或 90％也是不可取的。因为有一些语句比如说属性的赋值等没有被覆盖到也是正常的。这里不是说写了测试的程序就是好程序，但是至少可以降低出错的概率，而且看到测试一片绿灯心里还是很爽的。
异步代码测试
在实际的环境，代码可能是非常复杂的。比如说存在异步的情况。比如说网络连接，只要是网络连接的地方，为了保证界面的流畅性，大多数都是异步的。这就对测试造成了一定的麻烦，因为代码是按顺序执行的，可以还没等异步的结果出来，测试已经结束了。这里虽然可以通过GCD的方式来解决这个问题。但是不够优雅。Xcode6新增加了XCTestExpectation类来帮助我们测试异步的代码。
XCTestExpectation顾名思义就是期望。我们来设定一个期望，然后指定等待的时间，如果在时间内完成了期望，则测试通过，否则失败。
我们来看一个例子
先定义一个例子
#import <XCTest/XCTest.h>
typedef void (^oneBlock)(NSInteger index);
@interface UnitTestDemoTests : XCTestCase
@end
@implementation UnitTestDemoTests
- (void)asyncWithBlock:(oneBlock)test {
test(2);
}
- (void)testAsync {
[self asyncWithBlock:^(NSInteger index) {
XCTAssertEqual(index, 3,@"not 3");
}];
}
@end
这个测试应该是通不过的，但是实际上却成功了，这是为什么呢？值应该是2，期望是3，应该断言失败的，这里为什么成功了呢？因为这里代码是异步的，根本就没执行XCTAssertEqual(index, 3,@"not 3");这句话，相当于一个没有断言的测试方法，所以说测试通过了。
这里我们需要让代码稍微等一等，等我们执行完里面的代码再说。
所以我们改造一下代码
- (void)testAsync {
XCTestExpectation *expectation = [self expectationWithDescription:@""];
[self asyncWithBlock:^(NSInteger index) {
if (index ==3) {
[expectation fulfill];
}
}];
[self waitForExpectationsWithTimeout:2 handler:^(NSError *error) {
// cleanup.
}];
}
要做一个异步测试，首先使用建立一个期望值。
XCTestExpectation *expectation = [self expectationWithDescription:@""];
然后，在方法底部，增加 waitForExpectationsWithTimeout 方法，指定一个超时时间，如果测试条件在时间范围内没有获得期望便会结束执行：
[self waitForExpectationsWithTimeout:2 handler:^(NSError *error) {
// cleanup.
}];
现在，剩下的步骤是在异步方法被测试的相关的回调中实现那个期望值。
[expectation fulfill];
OK，这样就可以完成了异步代码的测试。
代码性能测试
最后是代码的性能测试，这里可以记录每次被测方法执行所需要的时间，执行完之后可以和以前的时间进行对比，可以设定一个基准值来进行比较。这个非常适合在代码重构或者性能优化之后进行测试，这样就可以很清楚的看到时间的变化。
将被测的代码写在measureBlock之中，然后进行测试。
[self measureBlock:^{
// Put the code you want to measure the time of here.
for (NSInteger i=0; i<100000; i++) {
}
}];
测试完之后可以看到左边有一个小白点，点击之后可以看到时间的变化。
这里原本是空的，我增加了10万次循环之后可以明显的看出时间在增加。
