iOS单元測试：Specta + Expecta + OCMock + OHHTTPStubs + KIF

框架选择

參考这篇选型文章，http://zixun.github.io/blog/2015/04/11/iosdan-yuan-ce-shi-xi-lie-dan-yuan-ce-shi-kuang-jia-xuan-xing/，尽管结论不一定全然适用，可是关于框架对照的地方还是值得阅读的。基于这篇文章，排除Kiwi框架之后，决定參考一些项目的源码，了解他们使用的測试方面的框架。

首先，參考https://github.com/artsy/eigen开源项目，其内部总体结构很完整，开发流程也很专业。至少比我知道的大多数国内团队都要专业：

eigen: Specta + OCMock + Expecta + OHHTTPStubs + FBSnapshotTestCase + "Expecta+Snapshots" + "XCTest+OHHTTPStubSuiteCleanUp”。

其次，參考公司内部别的项目使用情况。发现使用下面框架来做測试方面的事情： Specta + Expecta + OCMock + OHTTPStubs + KIF(UI Test)

so，我决定选择 Specta (BDD框架) + Expecta(断言框架) + OCMock(mock框架) + OHHTTPStubs(http stub框架) + KIF(UI Test) 做測试框架来学习。

XCTest简单介绍

因为我决定不直接使用XCTest作为測试框架。可是又因为Specta是基于XCTest进行封装的，所以对XCTest做一个基础的了解还是有必要的。

參考:

1. https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/testing_with_xcode

2. http://www.objc.io/issues/15-testing/xctest/，翻译：http://objccn.io/issue-15-2/

3. http://zixun.github.io/blog/2015/04/16/iosdan-yuan-ce-shi-xi-lie-dan-yuan-ce-shi-bian-ma-gui-fan/

BDD框架 — Specta

1. 简单介绍

眼下主流的BDD框架，这些BDD框架在语法层面差点儿是同样的，基本的差别在于他们的可配置能力和绑定的组件。

以下三个OC BDD框架相对于官方框架XCTest都具有更好的可读性。另外如今已经有了比較流行的swift BDD框架：https://github.com/railsware/Sleipnir 和 https://github.com/Quick/Quick。

关于specta与kiwi框架的对照，參考：http://appleprogramming.com/blog/2014/01/18/tdd-with-specta-and-expecta/，这篇文章的结论是specta相对于kiwi有更加优雅的语法，对于我这样的刚開始使用的新手，果断採用specta这样的各种完胜的框架。Specta框架具有一下特点:

  • An OC RSpec-like BDD DSL
  • Quick and easy set up
  • Build on top of XCTest
  • Excellent Xcode integration

2. Specta BDD DSL语法简单介绍

能够參考 https://github.com/specta/specta 官网和https://github.com/artsy/eigen项目中的test
case代码来学习语法

1) SpecBegin 声明了一个測试类。SpecEnd 结束了类声明

2) describe (context) 块声明了一组实例

3) it (example/specify) 是一个单一的样例

4) beforeAll 是一个执行于全部同级块之前的块，仅仅执行一次。afterAll 与beforeAll相反，是在全部同级块之后执行的块。仅仅执行一次。

5) beforeEach/afterEach，在每一个同级块执行的时候，都会执行一次，而beforeAll/afterAll仅仅会执行一次

6) it/waitUntil/done()。异步调用，注意完毕异步操作之后。必须调用done()函数。例如以下：

  • it(@"should do some stuff asynchronously", ^{

    waitUntil(^(DoneCallback done) {

    // Async example blocks need to invoke done() callback.

    done();

    });

    });

7) sharedExamplesFor 和 itShouldBehaveLike结合在一起。能够实如今不同的spec之间共享同一套test case，參考：http://artandlogic.com/2014/02/specta-shared-behavior/；sharedExamplesFor
设置多个spec之间共享的test case，第一个參数作为标识符。通过itShouldBehaveLike来执行spec中test case。第一个參数传入sharedExamplesFor设置时使用的标识符。注意。在describe局部使用sharedExamplesFor定义shared examples。能够在它作用域内覆盖全局的shared examples。

8) pending，仅仅打印一条log信息。不做測试。这个语句会给出一条警告，能够作为一開始集中书写行为描写叙述时还未实现的測试的提示。

断言框架 — Expecta

使用方法能够參考开源项目： https://github.com/artsy/eigen。从中找到相应的代码学习是最好的方式。假设须要找到很多其它更全面的使用方法，能够去项目官方站点：https://github.com/specta/expecta。截取一段eigen上面代码，基本上就能够了解Expecta框架的基本使用方法了，例如以下图中
expect(mapView.nextZoomScale).to.equal(mapView.annotationZoomScaleThreshold)

mock框架 —
OCMock

了解OCMock 2.x中的具体features。能够參考: http://ocmock.org/features/；了解OCMock 3.x的具体API。能够參考：http://ocmock.org/reference/；

什么是mock，refer: http://hackazach.net/code/2014/03/03/effective-testing-with-ocmock/：

In a modern Object Oriented system, the component under test will likely have several object dependencies. Instead of instantiating dependencies as concrete classes, we use mocks. Mocks are ‘fake’ objects with pre-defined behavior to stand-in for concrete objects during testing. The component under test does not know the difference! With mocks, a component can be tested with confidence that it behaves as designed within a larger system. 

OCMock框架的使用方法也比較简单，因为我个人时间比較紧张，仅仅能抽出一两天的时间学习測试部分的知识，就不多说了，以下几篇文章都说的比較清楚，能够參考：http://zixun.github.io/blog/2015/04/16/iosdan-yuan-ce-shi-xi-lie-yi-ocmockchang-jian-shi-yong-fang-shi/ ，学习2.x和3.x的API的基本使用。

另外能够參考开源项目 https://github.com/artsy/eigen，学习当中的OCMock
API的使用，框架使用比較简单，看看就懂了，不须要多说。

eigen的一个test case，注意在运行完成的时候，须要调用stopMocking。OCMockObject是基于runtime方法转发实现的。mock一个对象，就是对这个对象的方法进行转发的过程，运行完成须要调用stopMocking，否则会影响其它test case的运行。

以下能够看出一个OCMock基本过程：获得OCMockObject -> stub方法 -> 设置expect ->
verify校验运行结果 -> 调用stopMocking

以下有一个mock一个alert view show的过程

參考：

OHHTTPStubs

官方：https://github.com/AliSoftware/OHHTTPStubs。这个框架是基于NSURLProtocol实现的。之前正好看过这部分的仅仅是，整理来说。这个框架的源码并不复杂，但实现还是比較巧妙的。具体的介绍和使用，在github上面介绍的很清楚，框架本身使用也比較简单：

[OHHTTPStubs stubRequestsPassingTest:^BOOL(NSURLRequest *request) {

return [request.URL.host isEqualToString:@"mywebservice.com"];

} withStubResponse:^OHHTTPStubsResponse*(NSURLRequest *request) {

// Stub it with our "wsresponse.json" stub file (which is in same bundle as self)

NSString* fixture = OHPathForFile(@"wsresponse.json", self.class);

return [OHHTTPStubsResponse responseWithFileAtPath:fixture

statusCode:200 headers:@{@"Content-Type":@"application/json"}];

}];

这个框架的主要用法就是上面这个演示样例，用法非常明显易用。结合unit test使用的时候。须要使用网络请求的时候。能够在it或者beforeAll或者beforeEach的时候进行stub request。即上面这段代码的行为。可是不要忘记的是。须要在tear down的时候，即specta的afterAll的时候，记得调用 [OHHTTPStubs removeAllStubs] 。

注意，这里仅仅是使用NSURLProtocol来stub request。不会影响被測试的请求接口的測试。请求是异步的话，能够使用Specta的it/waitUntil/done()流程对请求进行測试，假设使用XCTest的话，OHTTPStubs给出了一个wiki解决。使用XCTestExpectation来搞定。我认为挺有意思：

- (void)testFoo

{

NSURLRequest* request = ...

XCTestExpectation* responseArrived = [self expectationWithDescription:@"response of async request has arrived"];

__block NSData* receivedData = nil;

[NSURLConnection sendAsynchronousRequest:request

queue:[NSOperationQueue mainQueue]

completionHandler:^(NSURLResponse* response, NSData* data, NSError* error)

{

receivedData = data;

[responseArrived fulfill];

}

];

[self waitForExpectationsWithTimeout:timeout handler:^{

// By the time we reach this code, the while loop has exited

// so the response has arrived or the test has timed out

XCTAssertNotNil(receivedData, @"Received data should not be nil");

}];

}

因为NSURLProtocol的局限性。OHHTTPStubs没法用来測试background sessions和模拟数据上传。

F.I.R.S.T 原则

优秀測试实践原则，https://pragprog.com/magazines/2012-01/unit-tests-are-first：

  • Fast — 測试应该可以被常常执行
  • Isolated — 測试本身不能依赖于外部因素或其它測试的结果
  • Repeatable — 每次执行測试都应该产生同样的结果
  • Self-verifying — 測试应该依赖于断言，不须要人为干预
  • Timely — 測试应该和生产代码一同书写

怎样将測试结果收益最大化：不要将測试和实现细节耦合在一起。

  • 不要測试私有方法
  • 不要Stub私有方法
  • 不要Stub外部库
  • 正确地Stub依赖
  • 不要測试构造函数

參考资料

时间： 2024-10-24 12:15:40

iOS单元測试：Specta + Expecta + OCMock + OHHTTPStubs + KIF的相关文章

iOS 单元測试之XCTest具体解释（一）

原创blog,转载请注明出处 blog.csdn.net/hello_hwc 欢迎关注我的iOS-SDK具体解释专栏 http://blog.csdn.net/column/details/huangwenchen-ios-sdk.html 前言:測试是一个好的App必不可少的部分.每个App都是由一个个小的功能组合到一起的. 而这些小的功能又是由一个个函数或者说算法组合到一起的.单元測试就是对这些小的功能或者函数进行測试,良好的单元測试会让代码的健壮性提高非常多.XCTest就是XCode为我

ios单元測试之GHUnit

1.相同创建一个測试的project, 2.通过cocoaPod来下载GHUnit框架,或者到github上下载.由于这个框架是开源的第三方框架. 同一时候加入QuartCore.framework(或者加入:GHUnitios.framework框架). 3.在项目的Build Setting 中国搜索other linker Flags,并将它的值设置为"-ObjC-all_load",这个表示连接外面oc框架在编译之后. 4.改动一下启动的入口文件(即为:main.m 函数):不

[iOS翻译]《iOS7 by Tutorials》在Xcode 5里使用单元測试（上）

简单介绍: 单元測试是软件开发的一个重要方面.毕竟,单元測试能够帮你找到bug和崩溃原因,而程序崩溃是Apple在审查时拒绝app上架的首要原因. 单元測试不是万能的,但Apple把它作为开发工具包的一部分,不仅让你创作的APP更稳定,并且提供了一致.有趣的用户体验,这些都是让用户给你五星评价的源泉.iOS7提供了一个升级的单元測试框架.让你在Xcode中执行单元測试更为easy.当你完毕这一章节,你将学会怎样给现有app加入測试--并有可能培养出对编写測试的热爱! /* 本文翻译自<iOS7

C语言单元測试

对于敏捷开发来说,单元測试不可缺少,对于Java开发来说,JUnit非常好,对于C++开发,也有CPPUnit可供使用,而对于传统的C语言开发,就没有非常好的工具可供使用,能够找到的有这么几个工具: CuTest -- CuTest(Cute Test)是一个很easy的C语言单元測试工具.在使用它的时候,仅仅须要包括两个文件“CuTest.c CuTest.h”,然后就能够写測试用例,进行測试了.它对用例差点儿没有管理功能,报表输出也很easy,能够用来试验单元測试的基本想法. CUnit -

Android 进行单元測试难在哪-part3

原文链接 : HOW TO MAKE OUR ANDROID APPS UNIT TESTABLE (PT. 1) 原文作者 : Matthew Dupree 译文出自 : 开发技术前线 www.devtf.cn 译者 : chaossss 校对者: tiiime 状态 : 完毕 在 Android 应用中进行单元測试非常困难.有时候甚至是不可能的.在之前的两篇博文中,我已经向大家解释了在 Android 中进行单元測试如此困难的原因.而上一篇博文我们通过分析得到的结论是:正是 Google 官

利用Continuous Testing实现Eclipse环境自己主动单元測试

当你Eclipse环境中改动项目中的某个方法时,你可能因为各种原因没有执行单元測试,结果代码提交,悲剧就可能随之而来. 所幸infinitest(http://infinitest.github.io/)提供了一个Continuous Testing插件,以及时自己主动执行单元測试.尽管会多占一些CPU资源,但开发者的硬件谁会不留一点余地呢?大不了,音乐.视频.360卸载就OK了.安装方法有两种: (1)使用"Install new software",输入地址:http://infi

玩转单元測试之WireMock -- Web服务模拟器

WireMock 是一个灵活的库用于 Web 服务測试,和其它測试工具不同的是.WireMock 创建一个实际的 HTTPserver来执行你的 Web 服务以方便測试. 它支持 HTTP 响应存根.请求验证.代理/拦截.记录和回放. 而且能够在单元測试下使用或者部署到測试环境. 它能够用在哪些场景下: 測试移动应用依赖于第三方REST APIs 创建高速原型的APIs 注入否则难于模拟第三方服务中的错误 不论什么单元測试的代码依赖于web服务的 文件夹 前提条件 Maven配置 准备工作 Ex

在Eclipse中使用JUnit4进行单元測试（0基础篇）

本文绝大部分内容引自这篇文章: http://www.devx.com/Java/Article/31983/0/page/1 我们在编写大型程序的时候,须要写成千上万个方法或函数,这些函数的功能可能非常强大,但我们在程序中仅仅用到该函数的一小部分功能,而且经过调试能够确定,这一小部分功能是正确的.可是,我们同一时候应该确保每个函数都全然正确,由于假设我们今后假设对程序进行扩展,用到了某个函数的其它功能,而这个功能有bug的话,那绝对是一件非常郁闷的事情.所以说,每编写完一个函数之后,都应该对这

新手学測试----Unit Test（单元測试）

在程序猿做项目的过程中,每当完毕一个功能,首先自己须要对完毕的功能进行測试.我如今正在做的项目用的工具是VS2012.那么接下来,就说一说在VS2012中是怎样创建单元測试的. 怎样创建单元測试? 在VS2012中,右键类名默认是没有创建单元測试的选项的,得须要设置加入.工具-->自己定义: 然后选择命令-->上下文菜单-->编辑器上下文菜单|代码窗体.然后找到创建单元測试,并将其上下移动到下图所看到的位置: 然后又一次打开VS.在类名上右键就能够看到灰色的创建单元測试,处于禁用状态: