单元测试的意义
在开发中我们需要测试我们的代码看看是否符合我们的预期，如果在每一次测试的时候我们都去找一个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的成员属性
- 在需要调用回调闭包的地方，不等待，直接调用
- 在单元测试中，在执行有异步回调闭包的方法之前，自己模拟给闭包中的属性设置预期值
小结：该方法就是直接跳过异步等待的时间，自己制造假的回调来使不稳定的异步执行方法变成“可测试的代码”。
网友评论