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
