swift在iOS开发中越来越普及,大家都认同swift将是iOS的未来,从objc切换到swift只是时间问题。但是,对于老的objc项目,特别是开发积累了2、3年的老项目,从objc转换到swift,基本上不太现实。
  那么,如何在老项目中使用swift呢?我想起了单元测试。单元测试,完全是使用另外的target,只要正确配置,基本上不会影响到主target。所以,在单元测试中,我们可以大胆且开心地使用swift,hooray~~~
  那么,为什么要写单元测试?有些人,可能觉得搞单元测试,要花更多的时间,写更多的代码,感觉不划算。但是,单元测试也有如下一些优点:
  · 使你自己更自信。
  · 代码不会退化。你不会因为修改了一个bug,而导致另外的bug。
  · 有良好的单元测试,可以进行大胆的重构了。
  · 良好的单元测试,本身是使用说明,有时比文档更有用。
  现在很多开源库、开源项目,都加了单元测试,如AFNetworking的swift版本,Alamofire,写了大量的测试代码:

  较复杂的开源项目,如firefox-ios,也会写一些测试代码:

  可以认为没有单元测试的开源项目,都是在耍流氓,:)
  单元测试中的基本概念
  TDD
  TDD(Test Drive Development),指的是测试驱动开发。我们一般的想法是先写产品代码,而后再为其编写测试代码。而TDD的思想,却是先写测试代码,然后再编写相应的产品代码。
  TDD中一般遵从red,green,refactor的步骤。因为,先编写了测试代码,而还未添加产品代码,所以编译器会给出红色报警。而后,你把相应的产品代码添加上后,并让它通过测试,此时是绿色状态。如此反复直到各种边界和测试都进行完毕,此时我们可以得到一个很稳定的产品。因为产品都有相关的测试代码,所以我们可以大胆进行重构,只要保证项目后是绿色状态,说明重构不会有问题。
  TDD的过程,有点像脚本语言的交互式编程,你敲几行代码,可以检查下结果,如果结果不对,则要把近的代码进行重写,直到结果正确为止。
  BDD
  BDD(Behavior Drive Development),行为驱动开发。它是敏捷中使用的测试方法,它提倡使用Given...When...Then这种类似自然语言的描述来写测试代码。如,Alamofire中下载的测试:
func testDownloadClassMethodWithMethodURLHeadersAndDestination() {
// Given
let URLString = "https://httpbin.org/"
let destination = Request.suggestedDownloadDestination(directory: searchPathDirectory, domain: searchPathDomain)
// When
let request = Alamofire.download(.GET, URLString, headers: ["Authorization": "123456"], destination: destination)
// Then
XCTAssertNotNil(request.request, "request should not be nil")
XCTAssertEqual(request.request?.HTTPMethod ?? "", "GET", "request HTTP method should be GET")
XCTAssertEqual(request.request?.URLString ?? "", URLString, "request URL string should be equal")
let authorizationHeader = request.request?.valueForHTTPHeaderField("Authorization") ?? ""
XCTAssertEqual(authorizationHeader, "123456", "Authorization header is incorrect")
XCTAssertNil(request.response, "response should be nil")
}
  Mock
  Mock让你可以检查某种情况下,一个方法是否被调用,或者一个属性是否被正确设值。比如,viewDidLoad()后,某些属性是否被设值。
  objc下可以使用OCMock来mock对象。但是,由于swift的runtime比较弱,所以,swift上一般要手动写mock。
  Stub
  如果你跟别人协同开发时,别人的模块还没有完成,而你需要用到别人的模块,这时,要用到Stub。比如,后端的接口未完成,而你的代码已经完成了。Stub可以伪造了一个调用的返回。
  ojbc下可以使用OHHTTPStubs来伪造网络的数据返回。swift下,仍要手动写stub。
  使用Quick+Nimble实现BDD
  为什么使用Quick
  上面Alamofire的例子中,它使用的是苹果的XCTest,所以你会看到它会写很长的函数名,每个Assert,后面还要写很长的注释。
  而Quick库,写起来是这样子的:

  它更符合BDD的思想,再配合Nimble这个expect库,出错提示也不用写,它自动生成的错误提示已经很可读了。
  另外,相比于其他BDD库,它是纯swift写的,可以更方便地用来测试objc代码、swift代码。
  注:目前也有很多开源项目,把测试从第三方BDD库换回到XCTest了,可能更看重XCTest的原生性,所以测试库的选择还是看个人了。
  使用Cocoapods导入库
  我们要使用Quick和Nimble库,可以使用Cocoapods进行管理。在Podfile中添加如下代码:
  use_frameworks!
  def testing_pods
  pod 'Quick', '~> 0.9.0'
  pod 'Nimble', '3.0.0'
  end
  target 'MyTests' do
  testing_pods
  end
  注: swift库在Podfile中,必须使用 use_frameworks!。但是,Cocoapods在这种情况下,会把所有的其他库也变成Frameworks动态库的方式。如果,你为了兼容,仍需要使用.a的静态库,则发布时,记得要注释掉该行。
  Quick使用
  Quick的使用很简单,基本上上面的那张图已经可以涵盖了。基本上类似如下:
  describe("a dolphin") {
  describe("its click") {
  context("when the dolphin is near something interesting") {
  it("is emitted three times") {
  // expect...
  }
  }
  }
  }
  另外,对每个group,可以添加beforeEach和afterEach,来进行setup和teardown(还是可以看上面那张图中的例子)。