码迷,mamicode.com
首页 > 移动开发 > 详细

ios測试框架的理解

时间:2017-07-10 10:34:22      阅读:182      评论:0      收藏:0      [点我收藏+]

标签:职责   断言   设计   active   ble   pod   运行   desc   隔离   

关于ios的測试

Cedar 、Specta 、Kiwi  、  XCTest
Specta和Kiwi的差别就是Kiwi包括了Specta和OCmock以及Expeata全部的功能

測试框架的作用:
因为行业中的干进度,所以我们一般都是不用TDD来測试,而是用BDD来測试。


BDD是用来測试的“数据存取”的重要环节。

“术语” 理解:
BDD(Behavior Driven Development),也就是行为驱动开发。它旨在解决详细问题,帮助开发者确定应该測试些什么。


TDD(Test-Driven Development)。就是測试驱动开发。通过測试来推动整个开发的进行。

gihub上面的框架:
oc 语言以上測试框架:
wiki   https://github.com/kiwi-bdd/Kiwi/wiki
specta https://github.com/specta/specta
Cedar  https://github.com/pivotal/cedar
XCTest 与xcode高度集成

swift语言的測试框架
https://github.com/railsware/Sleipnir
https://github.com/Quick/Quick


RAC  :IOS响应式编程框架ReactiveCocoa(RAC)使用演示样例

XCTest的解释:  ——> 简单  ,仅仅须要创建一个类。使用 “test” 作为測试方法名的前缀就可以。


XCTest与Xcode深度集成,并且能够享受Apple兴许对XCTest升级的福利。


上面可以看出XCTest仅仅是一个很easy使用,所以功能也是比較简单的,所以仅仅是可以用于中、小的项目其中。

“大”的project,——> Kiwi 或者 Specta
差别:
Kiwi包括了Specta和OCmock以及Expeata全部的功能。
Specta就是没有mock和验证功能Kiwi。


他们是不能够同一时候是使用的,可是它们能够各自和XCTest混合使用。

——> 原因:他们是对XCTest进行封装的。

上面的oc中的三大用来測试的框架各有利弊:
选择Kiwi是由于仅仅须要在podfile导入一个Kiwi即可了,
Specta则须要依赖别的第三方库。灵活。可是由于灵活而复杂。


使用Specta,还要引入OCmock/OCMockito以及Expeata/OCHamcrest一起配合使用。

OCMock Or OCMockito
这两个都是用来mock对象,Stub方法的,差别在于使用OCMock的库比OCMockito的库多。并且文档和教程更加丰富。
/*
mock測试就是在測试过程中。对于某些不easy构造或者不easy获取的对象,用一个虚拟的对象来创建以便測试的測试方法。
mock对象,这个虚拟的对象就是mock对象。mock对象就是真实对象在调试期间的取代品。


*/

Expecta Or OCHamcrest
都是断言的扩展框架,Expecta不成熟,框架另一些的问题。


OCHamcrest更加成熟,并且可扩展性高,能够自己定义自己的断言,更灵活。

specta框架的总结:在用specta的时候。一般都会再引入OCMock 和OCHamcrest 这两个一起使用。

BDD的理念: 不是写代码,而是讲故事。
整个故事是由Given…When…Then组成。
eg:BDD框架Kiwi的一段測试代码:
describe(@"Team", ^{
    context(@"when newly created", ^{
        it(@"has a name", ^{
            id team = [Team team]; [[team.name should] equal:@"Black Hawks"];
         });
        it(@"has 11 players", ^{
            id team = [Team team]; [[[team should] have:11] players];
         });
    });
});

这个測试用例就是在说Given a Team,When newly created,it should have a name, and should have 11 players,基本上不须要凝视就能知道在干嘛。

3、我们应该測试什么?
BDD:我们应该关注的是“行为” Behaviour而不是測试。
eg:比如你设计的一个对象,它有一个接口定义了其方法和依赖关系。

这些方法和依赖,声明了你对象的约定。它们定义了怎样与应用的其它部分交互,以及它的功能是什么。

它们定义了对象的行为。

同一时候这也应该是你的目标:測试你对象的行为方式。



不应该測试什么呢?
不要測试私有方法:
(私有方法意味着私有,假设你感到有必要測试一个私有方法,那么那个私有方法一定含有概念性错误,一般是作为私有方法,它做的太多了, 从而违背了单一职责原则)。
不要 Stub 私有方法:Stub 私有方法和測试私有方法具有同样的危害。更重要的是,Stub 私有方法将会使程序难以调试。通常来说。用于Stub的库会依赖于一些不平常的技巧来完毕工作,这使得发现一个測试为什么会失败变的困难。
不要測试构造函数:构造函数定义的是实现细节,你不应该測试构造函数,这是由于我们认同測试应该与实现细节解耦这一观点。
不要 Stub 外部库:第三方代码不应该在你的測试中直接出现。

4.測试的目的
使重构更简单 —— 你能够自信的改动实现细节,而不用去触及公有 API。
避免代码恶化—— 恶化在什么时候发生?在你改动代码的时候。
提供了可运行的说明和文档 —— 你在什么时候更想知道软件实际上是怎样工作的?在你想改动它们的时候。
降低了创建软件的时间 —— 怎么降低时间的?是通过更高速地改动你的代码,出错时測试会自信地告诉你哪里出错了。


减少了创建软件的代价 —— 时间就是金钱。朋友。

測试应该:
非常高速(Fast) —— 測试应该可以被常常运行。


能隔离(Isolated) —— 測试本身不能依赖于外部因素或者其它測试的结果。


可反复(Repeatable) —— 每次执行測试都应该产生同样的结果。


带自检(Self-verifying) —— 測试应该包含断言。不须要人为干预。
够及时(Timely) —— 測试应该和生产代码一同书写。

5.UI測试

关于UI測试,须要測试的是用户的交互,而不是应用的外观,Xcode7中新增了UI Testing,详细能够看wwdc 2015 session :406_hd_ui_testing_in_xcode。


參考链接:
http://www.cocoachina.com/ios/20150731/12859.html


ios測试框架的理解

标签:职责   断言   设计   active   ble   pod   运行   desc   隔离   

原文地址:http://www.cnblogs.com/jzdwajue/p/7144157.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!