關於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測試框架的理解