用 Swift 编写网络层单元测试
用 Swift 编写网络层单元测试
单元测试主要用来检测某个工作单元的结果是否符合预期，以此保证该工作单元的逻辑正确。上次写封装一个 Swift-Style 的网络模块的时候在结尾提了一下单元测试的重要性，评论中有朋友对网络层的单元测试有一些疑惑。我推荐他去看《单元测试的艺术》（这本书让我对单元测试有了新的认识），但由于该书是以 C# 为例写的，可能会对 iOS 开发的朋友造成一定的阅读障碍，所以我还是决定填一下坑，简单介绍一下用 Swift 进行网络层单元测试的方法。不过由于 Swift 的函数式特性，像《单元测试的艺术》中那样单纯地用 OOP 思维编写测试可能会有些麻烦，本文临近结尾部分写了一点自己用过的使用“伪装函数”进行测试的方法，可能大家以前没见过，我自己也是突然想到的，欢迎提出各种意见。
网络层的单元测试之所以让人感觉难以下手，原因主要有两点：
- 网络是个不稳定的外部依赖。
- 网络操作一般会涉及异步过程，而异步过程难以测试。
要直接测试网络和异步调用，可以使用XCTest提供的expectationWithDescription+waitForExpectationsWithTimeout，举个例子：
func testFetchDataWithAPI_invalidAPI_failureResult() {
let expectation = expectationWithDescription("")
let timeout = 15 as NSTimeInterval
NetworkManager
.defaultManager
.fetchDataWithAPI(.Invalid, responseKey: "") {
expectation.fulfill()
XCTAssertTrue($0.isFailure)
}
waitForExpectationsWithTimeout(timeout, handler: nil)
}测试方法按 test方法名_测试场景_期望结果 的格式命名。首先在异步回调外面调用expectationWithDescription方法得到一个expectation，这个方法接受一个字符串，用来描述本次测试，我传了个空串，因为我们的测试方法名已经足够清晰了。然后在回调中调用expectation.fulfill()表明满足测试条件，接下来就可以进行断言。最后别忘了在回调外面加上waitForExpectationsWithTimeout(timeout, handler: nil)，如果时间超过timeout回调还没有执行，就会测试失败，hander会在超时后调用，可以写一些清空状态和还原现场的操作，以免影响之后的测试，譬如task?.cancel()。但是我这边什么都没做，因为优秀的单元测试之间本来就不应该互相有影响。
上面的测试非常简单吧，但是按《单元测试的艺术》一书中的观点，这样的测试已经不能算是单元测试，而是步入集成测试的范畴了：
集成测试是对一个工作单元进行的测试，这个测试对被测试的工作单元没有完全的控制，并使用该单元的一个或多个真实的依赖物，例如时间、网络、数据库、线程或随机数产生器等。
上述这个测试非常不稳定，它依赖于真实的网络状况，我们可能因为网络不佳测试失败，而不是因为我们的代码本身有逻辑错误，而且这个测试有可能非常慢，慢到你不愿意每次一修改代码就去跑一遍测试，这样的单元测试就有可能形同虚设。
集成测试当然也非常重要，但一般开发人员也就写写单元测试。其实 Alamofire 就有采用我上面说的方法进行测试，所以如果你的网络层像我一样是以 Alamofire 为基础构建的，那就表示你不太需要再去写这样的测试了，你只要保证跟 Alamofire 无关的那些代码本身逻辑正确，以及正确调用了 Alamofire 即可。
譬如针对我的这个方法：
/**
Fetch raw object
- parameter api: API address
- parameter method: HTTP method, default = POST
- parameter parameters: Request parameters, default = nil
- parameter responseKey: Key of target value, use '.' to get nested objects, e.g. "data.vehicle_list"
- parameter jsonArrayHandler: Handle result with raw object
- returns: Optional request object which is cancellable.
*/
func fetchDataWithAPI(api: API,
method: Alamofire.Method = .POST,
parameters: [String: String]? = nil,
responseKey: String,
networkCompletionHandler: NetworkCompletionHandler) -> Cancellable? {
guard let url = api.url else {
printLog("URL Invalid: \\(api.rawValue)")
return nil
}
return Alamofire.request(method, url, parameters: parameters).responseJSON {
networkCompletionHandler(self.parseResult($0.result, responseKey: responseKey))
}
}我一般会去测试它的返回值是否符合预期：
func testFetchDataWithAPI_invalidURL_returnNil {
let task = NetworkManager
.defaultManager
.fetchDataWithAPI(.InvalidURL, responseKey: "") {}
XCTAssertNil(task)
}
func testFetchDataWithAPI_validAPI_returnNotNil {
let task = NetworkManager
.defaultManager
.fetchDataWithAPI(.ValidURL, responseKey: "") {}
XCTAssertNotNil(task)
}这两个测试基本可以保证检查 URL 是否合法的逻辑和调用 Alamofire 的逻辑正确。
由于该方法中使用了parseResult方法，当然我也要测试这个方法的正确性：
let testKey = "testKey"
let jsonDictWithError: [String: AnyObject] = ["code": 1]
let jsonDictWithoutData: [String: AnyObject] = ["code": 0]
let jsonDictWithData: [String: AnyObject] = ["testKey": "testValue"]
let manager = NetworkManager.defaultManager
let error = UMAError.errorWithCode(.Unknown)
func makeResultForFailureCaseWithError(error: NSError) -> Result<AnyObject, NSError> {
return Result<AnyObject, NSError>.Failure(error)
}
func makeResultForSuccessCaseWithValue(value: AnyObject) -> Result<AnyObject, NSError> {
return Result<AnyObject, NSError>.Success(value)
}
func testParseResult_failureCase_returnFailureCase() {
let result = makeResultForFailureCaseWithError(error)
let formattedResult = manager.parseResult(result, responseKey: testKey)
XCTAssertTrue(formattedResult.isFailure)
}
func testParseResult_successCaseWithCode1_returnFailureCaseWithCode1() {
let result = makeResultForSuccessCaseWithValue(jsonDictWithError)
let formattedResult = manager.parseResult(result, responseKey: testKey)
XCTAssertEqual(formattedResult.error!.code, 1)
}
func testParseResult_successCaseWithoutData_returnFailureCaseWithTransformFailed() {
let result = makeResultForSuccessCaseWithValue(jsonDictWithoutData)
let formattedResult = manager.parseResult(result, responseKey: testKey)
XCTAssertEqual(formattedResult.error!.code, ErrorCode.TransformFailed.rawValue)
}
func testParseResult_successCaseWithData_returnTestValue() {
let result = makeResultForSuccessCaseWithValue(jsonDictWithData)
let formattedResult = manager.parseResult(result, responseKey: testKey)
XCTAssertEqual(String(formattedResult.value!), "testValue")
}这个测试也是测试返回值，测试了几种可能发生的情况，基本可以保证parseResult方法的正确性。
工作单元可能有三种最终结果：返回值、改变系统状态和调用第三方对象。相应的单元测试一般可以分为三类：基于返回值的测试、基于状态的测试和交互测试。我上面几个测试都是在测试返回值，这种测试最简单直接也最好维护。要测试状态的改变一般需要先测试初始状态，然后调用改变状态的方法，再测试改变后的状态。而交互测试可能就需要用到 fake （伪对象），fake 分为 stub （存根）和 mock （模拟对象）两种。stub 和 mock 很类似，它们最大的区别是，你会对 mock 进行断言，但不会对 stub 进行断言。换句话说，一旦你对一个 fake 进行断言了，它就是个 mock，否则就是个 stub。
由于 Swift 的反射非常弱鸡，似乎并没有什么特别好用的 mock 框架，所以一般来说可以用面向协议的思想来减少对象间的耦合，然后手动构建一个 fake 用于测试，当然这需要一些依赖注入技术的配合。又因为 Alamofire 对外暴露的最常用函数request是个全局函数，而它又会返回一个Request对象，我们要在该对象上调用responseJSON方法，这样一来光用伪对象似乎不足以满足需求。
Swift 毕竟是一门对 FP 支持度很高的语言，所以工作单元还可能有第四种最终结果——调用第三方函数（这个说法好像怪怪的，领会精神啊哈哈）。那相对应的，我们当然可以使用一个 fake function（伪函数，同样领会精神即可……）来配合测试。依旧以我的 NetworkManager 为例，稍加改造，方便在测试时注入伪函数和伪对象：
typealias NetworkCompletionHandler = Result<AnyObject, NSError> -> Void
typealias NetworkRequest = (Alamofire.Method,
URLStringConvertible,
[String : AnyObject]?,
Alamofire.ParameterEncoding,
[String : String]?) -> Responsable
protocol Responsable: Cancellable {
func responseJSON(queue queue: dispatch_queue_t?,
options: NSJSONReadingOptions,
completionHandler: Alamofire.Response<AnyObject, NSError> -> Void) -> Self
}
extension Alamofire.Request: Responsable {}
class NetworkManager {
// static 属性自带 lazy 效果，加上 let 可用作单例
static let defaultManager = NetworkManager(request: Alamofire.request)
let request: NetworkRequest
init(request: NetworkRequest) {
self.request = request
}
/**
Fetch raw object
- parameter api: API address
- parameter method: HTTP method, default = POST
- parameter parameters: Request parameters, default = nil
- parameter responseKey: Key of target value, use '.' to get nested objects, e.g. "data.vehicle_list"
- parameter jsonArrayHandler: Handle result with raw object
- returns: Optional request object which is cancellable.
*/
func fetchDataWithAPI(api: API,
method: Alamofire.Method = .POST,
parameters: [String: String]? = nil,
responseKey: String,
networkCompletionHandler: NetworkCompletionHandler) -> Cancellable? {
guard let url = api.url else {
printLog("URL Invalid: \\(api.rawValue)")
return nil
}
return request(method, url, parameters, .URL, nil).responseJSON(queue: nil, options: .AllowFragments) {
networkCompletionHandler(self.parseResult($0.result, responseKey: responseKey))
}
}
// ...
}我声明了一个新的类型NetworkRequest，它其实是个函数，签名跟 Alamofire 中的全局函数request一致。用户使用时只需调用defaultManager即可，而测试时我们可以手动构建一个符合NetworkRequest签名的函数通过初始化方法注入到NetworkManager中。我还声明了一个Responsable的协议，然后用extension 显式声明 Alamofire 中的Request遵守该协议，这个协议可以让我们在测试时构建一个代替Request的 fake 对象。
好了，万事俱备，开始写测试用例：
func testFetchDataWithAPI_requestWithMock_resultWithErrorCode666() {
struct MockResponse: Responsable {
func responseJSON(queue queue: dispatch_queue_t?,
options: NSJSONReadingOptions,
completionHandler: Alamofire.Response<AnyObject, NSError> -> Void)
-> MockResponse {
let unknowError = UMAError.errorWithCode(666, description: "error for test")
let result = Result<AnyObject, NSError>.Failure(unknowError)
let response = Alamofire.Response(request: nil, response: nil, data: nil, result: result)
completionHandler(response)
return self
}
func cancel() {}
}
let request: NetworkRequest = {_, _, _, _, _ in return MockResponse() }
let testableManager = NetworkManager(request: request)
testableManager.fetchDataWithAPI(.PostCategory, responseKey: "data") {
XCTAssertEqual($0.error!.code, 666)
}
}我觉得这是非常具有 Swift 风格的单元测试，不知道别人有没有用过。