ios測试框架的理解
关于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