[iOS笔记]单元测试

单元测试的意义

在开发中我们需要测试我们的代码看看是否符合我们的预期，如果在每一次测试的时候我们都去找一个ViewController的viewDidLoad方法来测试，这样不仅测试代码杂乱，而且测试的时候也麻烦。这时候就需要我们使用单元测试去完成我们需要的测试。通过测试可以让我们的程序少一点Bug，及时的测试也有助于减少我们找后面找Bug的时间。

使用Xcode进行单元测试

在构建项目的时候，可以勾选下方的 Include Unit Tests，这样Xcode会帮我们自动创建单元测试

新建项目.png

在项目里面直接添加Unit Test Case Class

项目内添加文件.png

这样在项目中我们就能看到下面的单元测试文件

import XCTest
@testable import <#你的项目名#>

class UnitTest: XCTestCase {
    
    override func setUp() {
        super.setUp()
        // 这里放测试用例中执行前需要初始化和设置的代码
    }
    
    override func tearDown() {
        // 这里放测试用例结束后需要执行的后续操作代码
        super.tearDown()
    }
    
    // 单元测试的方法名开头必须有test，名字上最好将测试的内容都表示清楚
    func testExample() {
        // 测试的内容
        // 使用 XCTAssert 去查看测试的结果是否符合预期（类似断言的用法）
    }
    
}

可测试代码

进行单元测试的一个重要前提，就是我们要测试的代码是“可测试”（testable code）的，是指代码的测试要满足一些条件，包括：

测试过程要不依赖于任何外部条件和系统；
在任何环境、测试任意多次，结果应该保持不变；

依赖注入

我们管在init中可以传入其它依赖对象的方式，就叫做依赖注入（ependency Injection）。
在单元测试中，我们可以将要测试的对象抽出来，使用依赖注入来传入其他的对象来进行测试

Mock

在测试中，我们有时为了保证测试的结果保持不变，不能使用真的类型的对象，还需要创造一个假的类型使用一个假的对象来模拟。那怎么去做一个假的对象了，那就是下面使用Swift的protocol来做的Mock的思路了：

假如我们想做一个Xxx类型的MockXxx类型

定义protocol（XxxProtocol）来模拟一个原先的类型，定义出原先类型中需要测试的方法
使用extension来使原先的类型（Xxx）遵守上面的protocol（XxxProtocol）
在程序中需要测试的位置中原先的类型（Xxx）就可以改成遵守了上述protocol的类型（XxxProtocol）
创建一个Mock的类（MockXxx），遵守上述的protocol（XxxProtocol），实现里面需要测试的方法

使用上面的套路，我们就可以使用Swift的Protocol方便快捷的做出一个用于测试的假对象了

测试异步执行的回调函数

方法一

使用XCTestExpectation，简单来说，就是允许我们在一个时间范围里，给Xcode设置一个“期望”，如果期望满足了就表示测试成功，如果超时了，就表示测试失败。

// 创建 expect
let expect = expectation(description: <#描述#>)

// 在异步执行中条件满足的地方放置“满足”
expect.fulfill()

// 给“期望值”设置一个超时时间，在需要等待的地方调用
waitForExpectations(timeout: <#需要等待的秒数#>, handler: nil)

// 下面就使用 XCTAssert 去验证自己的测试

这样，只要在需要等待的秒数之内得到了返回值，测试就会成功，否则，就会失败。

通过Xcode expectation也只能部分解决我们的问题，对于测试异步执行的代码，这种方式仍有一些问题的。如果测试的是网络方法，我们无法去保证测试方法的等待秒数，而且有些网络方法有不一样的超时时间，这样这个需要等待的秒数就难以有一个统一的数字。

方法二

通过上边的mock串行化异步执行的代码：

将异步回调闭包中的属性都设成MockXxx的成员属性
在需要调用回调闭包的地方，不等待，直接调用
在单元测试中，在执行有异步回调闭包的方法之前，自己模拟给闭包中的属性设置预期值

小结：该方法就是直接跳过异步等待的时间，自己制造假的回调来使不稳定的异步执行方法变成“可测试的代码”。