今天刷完了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 

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万次循环之后可以明显的看出时间在增加。

iOS Unit Test