iOS開發中的測試框架
作者：@crespoxiao 授權本站轉載。
我們為什麼要用測試框架呢？當然對項目開發有幫助了，但是業內現狀是經常趕進度，所以TDD還是算了吧，BDD就測測數據存取和重要環節，這很重要，一次性跑完測試單元檢查接口或模塊的可用性，這比打斷點調試強多了吧，至於UI測試就算了吧（xcode7集成了），呵呵。
首先了解一下BDD與TDD的概念：
BDD（Behavior Driven Development），也就是行為驅動開發，它旨在解決具體問題，幫助開發人員確定應該測試些什麼。
TDD（Test-Driven Development），就是測試驅動開發，通過測試來推動整個開發的進行。
github上搜TDD或BDD，語言選擇objective-c，star最多的就是這2個：
https://github.com/kiwi-bdd/Kiwi/wiki
https://github.com/specta/specta
還有一個測試框架用的比較少，叫Cedar https://github.com/pivotal/cedar
此外，還找到2個Swift的測試框架，以後用Swift開發可以考慮使用：
https://github.com/railsware/Sleipnir
https://github.com/Quick/Quick
Cedar，Specta和Kiwi這3個框架就是目前Objc最流行的BDD測試框架了，其中Kiwi最受歡迎（根據github上的star數來推斷，行為描述和期望寫起來也比較易懂，至少我是這麼認為的）。
不過，Specta是 RAC 那幫人維護的，用於測試的黑魔法更多，我擔心這幫人精力太分散顧及不上這個測試框架。但是有些使用測試框架經驗豐富的人選擇用回了XCTest，主要是因為它跟Xcode集成的比較好，而且嫌BDD框架hold不住業務的發展，cmd+u可以一次性跑完所有的測試(試過3個框架目前都可以這樣的)。
XCTest與Xcode深度集成，而且可以享受Apple後續對XCTest升級的福利。XCTest 的優勢和缺點都是由於它太簡單了。你只需要創建一個類，使用 “test” 作為測試方法名的前綴，只需要這樣就可以了，不需要再做其他的。不幸的是，這已經是 XCTest 的全部優點了。BDD 框架的附加功能的重要性是取決於項目的大小。我的結論是，XCTest 對中小型的工程來說是一個很好的選擇，但是對於更大型的工程，就有必要參考一下像 Kiwi 或者 Specta 這樣的 BDD 框架。Specta和Kiwi的區別就是Kiwi包含了Specta和OCmock以及Expeata所有的功能。換句話說Specta就是沒有mock和驗證功能Kiwi。經測試，Kiwi與Specta是不能同時在項目中使用的，會Crash,不信你試試，不過各自可以與XCTest混合使用因為它們是基於XCTest封裝的。
Cedar，Kiwi，以及 Specta 提供類似語法，我不能說其中一個框架要比其他所有都好，它們各有利弊，選擇 BDD 框架歸根結底來自個人偏好。我選擇Kiwi是因為只需要在podfile導入一個Kiwi就行了，Specta則需要依賴別的第三方庫，雖然靈活，但靈活有靈活的壞處，當然也有好處，你喜歡就好，反正用得不爽別怨我。
如果使用Specta，還要引入OCmock/OCMockito以及Expeata/OCHamcrest一起配合使用。
OCMock Or OCMockito
這兩個都是用來mock對象，Stub方法的，他們之間的區別在於使用OCMock的庫比OCMockito的庫多，而且文檔和教程更加豐富。
Expecta Or OCHamcrest
這兩個都是斷言的擴展框架，Expecta不成熟，框架還有一些的問題。OCHamcrest更加成熟，而且可擴展性高，可以自定義自己的斷言，更靈活。
BDD的理念是你不是在寫代碼，而是在講故事。而整個故事是由Given…When…Then組成。我們可以來看看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，基本上不需要注釋就能知道在干嘛。
參考：http://onevcat.com/2014/05/kiwi-mock-stub-test/
不同類型的模擬對象的基本定義：
double 可以理解為置換，它是所有模擬測試對象的統稱，我們也可以稱它為替身。一般來說，當你創建任意一種測試置換對象時，它將被用來替代某個指定類的對象。
stub 可以理解為測試樁，它能實現當特定的方法被調用時，返回一個指定的模擬值。如果你的測試用例需要一個伴生對象來提供一些數據，可以使用 stub 來取代數據源，在測試設置時可以指定返回每次一致的模擬數據。
spy 可以理解為偵查，它負責匯報情況，持續追蹤什麼方法被調用了，以及調用過程中傳遞了哪些參數。你能用它來實現測試斷言，比如一個特定的方法是否被調用或者是否使用正確的參數調用。當你需要測試兩個對象間的某些協議或者關系時會非常有用。
mock 與 spy 類似，但在使用上有些許不同。spy 追蹤所有的方法調用，並在事後讓你寫斷言，而 mock 通常需要你事先設定期望。你告訴它你期望發生什麼，然後執行測試代碼並驗證最後的結果與事先定義的期望是否一致。
fake 是一個具備完整功能實現和行為的對象，行為上來說它和這個類型的真實對象上一樣，但不同於它所模擬的類，它使測試變得更加容易。一個典型的例子是使用內存中的數據庫來生成一個數據持久化對象，而不是去訪問一個真正的生產環境的數據庫。
實踐中，這些術語常常用起來不同於它們的定義，甚至可以互換。它們自認為自己是 "mock 對象框架"，但是其實它們也提供 stub 的功能，不要太過於陷入這些詞匯的細節。
下面講講Kiwi的使用，盡量簡單，以便快速上手，當然詳情還是得看官方文檔，鏈接奉上：
https://github.com/kiwi-bdd/Kiwi/wiki
http://onevcat.com/2014/02/ios-test-with-kiwi/
1.Kiwi的安裝
podfile中寫入
target 'OneTravelTests', :exclusive => true do pod 'Kiwi' end
然後pod install或pod update就可以了。
可以安裝一個xcode插件http://alcatraz.io，裡面有Kiwi的template，安裝一下，然後就可以使用Kiwi了。然而有人說插件用不了，怪我咯？懶得解釋了，看這裡吧：
https://github.com/cikelengfeng/RPAXU
2.Kiwi的基本語法解釋
上3張圖，一切盡在不言中。
kiwi基本語法解釋
mock與stub解釋
測試數據請求
3.我們應該/不應該測試什麼
BDD 的第一個單詞就表明了這一點，你不應該關注於測試，而是應該關注行為。這個看似毫無意義的變化提供了應該測試什麼的准確答案：你應該測試行為。
例如你設計的一個對象，它有一個接口定義了其方法和依賴關系。這些方法和依賴，聲明了你對象的約定，它們定義了如何與應用的其他部分交互，以及它的功能是什麼。它們定義了對象的行為。同時這也應該是你的目標：測試你對象的行為方式。
不應該測試什麼呢？
不要測試私有方法：私有方法意味著私有，如果你感到有必要測試一個私有方法，那麼那個私有方法一定含有概念性錯誤，通常是作為私有方法，它做的太多了， 從而違背了單一職責原則。
不要 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.objc.io
