用 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 风格的单元测试,不知道别人有没有用过。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏java一日一条

深入理解 Java 中的 try-with-resource

众所周知,所有被打开的系统资源,比如流、文件或者Socket连接等,都需要被开发者手动关闭,否则随着程序的不断运行,资源泄露将会累积成重大的生产事故。

1622
来自专栏13blog.site

Mybatis-Generator生成Mapper文件中<if test="criteria.valid">的问题解答

写在前面 由于开源了项目的缘故,很多使用了My Blog项目的朋友遇到问题也都会联系我去解决,有的是把问题留在项目的issue里提出,有的是在我的私人博客里留言...

3436
来自专栏C/C++基础

CVTE2017秋季校招笔试题回忆(C++后台岗)

2016.09.06晚参加了CVTEC++岗的在线笔试。笔试题型分为不定向选择题和编程题,总共27题。其中不定项选择题为25道,编程题2道。其特点是不定项选择题...

1121
来自专栏非典型技术宅

Swift多线程:使用Thread进行多线程间通讯,协调子线程任务1. Thread的三种建立方式2. Thread的基本使用3. 使用NSCondition实现线程间通讯4. pthread

2112
来自专栏互联网高可用架构

白话阿里巴巴Java开发手册(异常日志)

4562
来自专栏Java架构师进阶

Java 10 新特性全览

在 Java 9 之后,Java 将采用基于时间发布的策略,每 6 个月一个版本。目前,Java 10 的新特性都已经确定。

914
来自专栏北京马哥教育

有关bash,我希望我能知晓的十件事

1795
来自专栏AI派

真是绝了!史上最详细的Jupyter Notebook入门教程

Jupyter Notebook 是一个在浏览器中使用的交互式的笔记本,可以实现将代码、文字完美结合起来,它的受众群体大多数是一些从事数据科学领域相关(机器学习...

1.1K8
来自专栏漏斗社区

CTF| SQL注入之获取数据类

上周发了一篇 SQL注入登录类的题型文章分析,这种题目一般是绕过登录限制。常规的SQL注入题需要我们一步步注入出数据,大部分题目需要我们有一定代码审计的能力,分...

4227
来自专栏向治洪

Mpg123源代码详解

Mpg123与libmad一样,支持mpeg1,2,2.5音频解码。目前来看mpg123比libmad支持了网络播放功能。而且libmad基本上开源社区在200...

2277

扫码关注云+社区

领取腾讯云代金券