iOS開發中的測試架構 （轉載）

標籤：

  

CrespoXiao授權地址：http://www.jianshu.com/p/7e3f197504c1

我們為什麼要用測試架構呢？當然對項目開發有協助了，但是業內現狀是經常趕進度，所以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 是一個具備完整功能實現和行為的對象，行為上來說它和這個類型的真實對象上一樣，但不同於它所類比的類，它使測試變得更加容易。一個典型的例子是使用記憶體中的資料庫來產生一個資料持久化對象，而不是去訪問一個真正的生產環境的資料庫。

 

實踐中，這些術語常常用起來不同於它們的定義，甚至可以互換。它們自認為自己是 "模擬物件架構"，但是其實它們也提供 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

 

 

 

 

  

iOS開發中的測試架構 （轉載）