用 Swift 编写网络层单元测试

 

单元测试主要用来检测某个工作单元的结果是否符合预期,以此保证该工作单元的逻辑正确。上次写封装一个 Swift-Style 的网络模块的时候在结尾提了一下单元测试的重要性,评论中有朋友对网络层的单元测试有一些疑惑。我推荐他去看《单元测试的艺术》(这本书让我对单元测试有了新的认识),但由于该书是以 C# 为例写的,可能会对 iOS 开发的朋友造成一定的阅读障碍,所以我还是决定填一下坑,简单介绍一下用 Swift 进行网络层单元测试的方法。不过由于 Swift 的函数式特性,像《单元测试的艺术》中那样单纯地用 OOP 思维编写测试可能会有些麻烦,本文临近结尾部分写了一点自己用过的使用“伪装函数”进行测试的方法,可能大家以前没见过,我自己也是突然想到的,欢迎提出各种意见。

网络层的单元测试之所以让人感觉难以下手,原因主要有两点:

  • 网络是个不稳定的外部依赖。
  • 网络操作一般会涉及异步过程,而异步过程难以测试。

要直接测试网络和异步调用,可以使用XCTest提供的expectationWithDescription+waitForExpectationsWithTimeout,举个例子:

测试方法按 test方法名_测试场景_期望结果 的格式命名。首先在异步回调外面调用expectationWithDescription方法得到一个expectation,这个方法接受一个字符串,用来描述本次测试,我传了个空串,因为我们的测试方法名已经足够清晰了。然后在回调中调用expectation.fulfill()表明满足测试条件,接下来就可以进行断言。最后别忘了在回调外面加上waitForExpectationsWithTimeout(timeout, handler: nil),如果时间超过timeout回调还没有执行,就会测试失败,hander会在超时后调用,可以写一些清空状态和还原现场的操作,以免影响之后的测试,譬如task?.cancel()。但是我这边什么都没做,因为优秀的单元测试之间本来就不应该互相有影响。

上面的测试非常简单吧,但是按《单元测试的艺术》一书中的观点,这样的测试已经不能算是单元测试,而是步入集成测试的范畴了:

集成测试是对一个工作单元进行的测试,这个测试对被测试的工作单元没有完全的控制,并使用该单元的一个或多个真实的依赖物,例如时间、网络、数据库、线程或随机数产生器等。

上述这个测试非常不稳定,它依赖于真实的网络状况,我们可能因为网络不佳测试失败,而不是因为我们的代码本身有逻辑错误,而且这个测试有可能非常慢,慢到你不愿意每次一修改代码就去跑一遍测试,这样的单元测试就有可能形同虚设。

集成测试当然也非常重要,但一般开发人员也就写写单元测试。其实 Alamofire 就有采用我上面说的方法进行测试,所以如果你的网络层像我一样是以 Alamofire 为基础构建的,那就表示你不太需要再去写这样的测试了,你只要保证跟 Alamofire 无关的那些代码本身逻辑正确,以及正确调用了 Alamofire 即可。

譬如针对我的这个方法:

我一般会去测试它的返回值是否符合预期:

这两个测试基本可以保证检查 URL 是否合法的逻辑和调用 Alamofire 的逻辑正确。

由于该方法中使用了parseResult方法,当然我也要测试这个方法的正确性:

这个测试也是测试返回值,测试了几种可能发生的情况,基本可以保证parseResult方法的正确性。

工作单元可能有三种最终结果:返回值、改变系统状态和调用第三方对象。相应的单元测试一般可以分为三类:基于返回值的测试、基于状态的测试和交互测试。我上面几个测试都是在测试返回值,这种测试最简单直接也最好维护。要测试状态的改变一般需要先测试初始状态,然后调用改变状态的方法,再测试改变后的状态。而交互测试可能就需要用到 fake (伪对象),fake 分为 stub (存根)和 mock (模拟对象)两种。stub 和 mock 很类似,它们最大的区别是,你会对 mock 进行断言,但不会对 stub 进行断言。换句话说,一旦你对一个 fake 进行断言了,它就是个 mock,否则就是个 stub。

由于 Swift 的反射非常弱鸡,似乎并没有什么特别好用的 mock 框架,所以一般来说可以用面向协议的思想来减少对象间的耦合,然后手动构建一个 fake 用于测试,当然这需要一些依赖注入技术的配合。又因为 Alamofire 对外暴露的最常用函数request是个全局函数,而它又会返回一个Request对象,我们要在该对象上调用responseJSON方法,这样一来光用伪对象似乎不足以满足需求。

Swift 毕竟是一门对 FP 支持度很高的语言,所以工作单元还可能有第四种最终结果——调用第三方函数(这个说法好像怪怪的,领会精神啊哈哈)。那相对应的,我们当然可以使用一个 fake function(伪函数,同样领会精神即可……)来配合测试。依旧以我的 NetworkManager 为例,稍加改造,方便在测试时注入伪函数和伪对象:

我声明了一个新的类型NetworkRequest,它其实是个函数,签名跟 Alamofire 中的全局函数request一致。用户使用时只需调用defaultManager即可,而测试时我们可以手动构建一个符合NetworkRequest签名的函数通过初始化方法注入到NetworkManager中。我还声明了一个Responsable的协议,然后用extension 显式声明 Alamofire 中的Request遵守该协议,这个协议可以让我们在测试时构建一个代替Request的 fake 对象。

好了,万事俱备,开始写测试用例:

我觉得这是非常具有 Swift 风格的单元测试,不知道别人有没有用过。

1 2 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部