愛上iOS單元測試系列之愛上她就要先瞭解她：單元測試入門

標籤：

前言

對於單元測試一開始我是拒絕的。單元測試是一個什麼東東，因為我喜歡做iOS開發是因為喜歡寫APP的啊，一切和這一目標不相干的東西我沒興趣啊，所以從事iOS開發幾年都沒去深入學習過單元測試（主要是之前單位沒這要求）。看到我的優點木有：目標性很強，嗯，記住我的優點，請忽略我拒絕學習邊緣知識的缺點。但是最近被總監要求負責單元測試的探索和落地，我義（勉）不（為）容（其）辭（難）地扛起了奪取橋頭堡的重任。隨著對這個姑娘的不斷的瞭解和接觸，我發現自己逐漸愛上了她，她有著獨立知性的氣質，有著完美豐滿的身材，有著自我成長過程中不斷豐富而且深刻的閱曆。她是如此地完美的，讓我神魂顛倒，夜不能寐，我想為她寫詩（可惜沒有文學細胞），我想為她寫歌（可惜沒有藝術細胞），我想為她寫書立傳（可惜沒有寫作天賦）。講真：有木有有眼無珠的出版社願意邀約？我真的想寫一本單元測試的書，我先寫幾篇關於的她的文章，您看看我有沒有出這本書的潛力。

我先來給你介紹下這位姑娘。

單元測試的魅力

每個男人都有過自己喜歡的女孩，可能還有多個，他們可能有你喜歡的共同特質，比如有人喜歡個子高的，有人喜歡小巧的，也有喜歡豐滿的，有人喜歡可愛的，有人喜歡野蠻的，也有喜歡……此處省略各種奇葩極端偏好，畢竟人各有所好嘛。但身為一名合格的程式員，你理想的中的女神，如果她有如下優點，一定會讓你愛的無法自拔：

1.她能讓你更自信。協助你編寫高品質代碼、減少bug。
如果大家分析一下我們bug原因的構成，我想有會有一部分bug的原因是開發人員在編寫工作代碼的時候沒有考慮到某些case或者邊際條件。造成這種問題的原因很多，其中很重要的一個原因是我們對工作代碼所要完成的功能思考不足，而編寫單元測試，特別是先寫單元測試再寫工作代碼就可以協助開發人員思考編寫的代碼到底要實現哪些功能。例如實現一個簡單的使用者註冊功能的業務類方法，用單元測試再寫工作代碼的方式來工作的話開發人員就會先考慮各種情境相關，例如正常註冊、使用者名稱重複、沒有滿足必要的填寫內容......等等，之後就會編寫相關的測試案例。編寫單元測試代碼的過程就是促使開發人員思考工作代碼實現內容和邏輯的過程，之後實現工作代碼的時候，開發人員思路會更清晰，實現代碼的品質也會有相應的提升。
2.她能提提升你的戰鬥力。協助你提升代碼的反饋速度，減少重複工作，提高開發效率。 
開發人員實現某個功能或者修補了某個bug，如果有相應的單元測試支援的話，開發人員可以馬上通過運行單元測試來驗證之前完成的代碼是否正確，而不需要反覆通過編譯運行simulator、等待應用啟動、通過輸入資料等繁瑣的步驟來驗證所完成的功能。用單元測試代碼來驗證代碼和通過發布應用以人工的方式來驗證代碼這兩者的效率差很多，所以單元測試其實還能節約人力成本。
3.她的存在讓你輕鬆愉快。保證你最後的代碼修改不會破壞之前代碼的功能。 
項目越做越大，代碼越來越多，特別涉及到一些公用介面之類的代碼或是底層的基礎庫，誰也不敢保證這次修改的代碼不會破壞之前的功能，所以與此相關的需求會被擱置或延遲，由於不敢改進代碼，代碼也變得越來越難以維護，品質也越來越差。而單元測試就是解決這種問題的很好方法（不敢說最好的）。由於代碼的曆史功能都有相應的單元測試保證，修改了某些代碼以後，通過運行相關的單元測試就可以驗證出新調整的功能是否有影響到之前的功能。當然要實現到這種程度需要很大的付出，不但要能夠達到比較高的測試覆蓋率，而且單元測試代碼的編寫品質也要有保證。
4.她能為你排憂解難，永遠做你的依靠。讓你的代碼維護更容易。 
由於給代碼寫很多單元測試，相當於給代碼加上了規格說明書，開發人員通過讀單元測試代碼也能夠協助開發人員理解現有代碼。很有Open Source的項目(如，AFNetworking, FMDB,喵神的VVDoucment等)都有相當量的單元測試代碼，通過讀這些測試代碼會有助於理解生產原始碼。
5.她甘心做你堅強的後盾，在你賣命打拚時無後顧之憂。她有助於改進代碼品質和設計。 
除了那些大拿們編寫的代碼，我相信很多易於維護、設計良好的代碼都是通過不斷的重構才得到的。雖然說單元測試本身不能直接改進生產代碼的品質，但它為生產代碼提供了“安全網”，讓開發人員可以勇敢地改進代碼，從而讓代碼的clean和beautiful不再是夢想。

我這麼辛苦把它吹的這麼有魅力，要是你作為程式員還不想見見她，wakao,我猜你不正常，有必要做個自身能力檢查。如果你跟我一樣是一個正常人，下面我就暫不收費，帶你遠遠的瞧上一瞧這位美女，看看她到底長什麼樣子。

iOS單元測試初探

維基百科上的對她解釋：“在電腦編程中，單元測試（又稱為模組測試, Unit Testing）是針對程式模組（軟體設計的最小單位）來進行正確性檢驗的測試工作。程式單元是應用的最小可測試組件。在過程化編程中，一個單元就是單個程式、函數、過程等；對於物件導向編程，最小單元就是方法，包括基類（超類）、抽象類別、或者衍生類別（子類）中的方法。”。

通常來說，程式員每修改一次代碼就會修改某個單元，那我們就可以對這個單元做修改的驗證（單元測試），在編寫程式的過程中前後很可能要進行多次單元測試，以證實程式達到軟體規格書（產品需求）要求的工作目標，而且沒有程式錯誤。雖然單元測試不是什麼必須的，但也不壞，這牽涉到專案管理的政策決定（說白了，你沒有她也能活，但是只能自己左手寫代碼，右手……當然也是寫代碼，作為程式員怎麼可以一隻手敲代碼呢）。

1.瞭解XCode中的單元測試

在XCode7中建立一個工程的時候，會預設帶一個用於單元測試的target，其名字為工程名加Test尾碼，並且檔案名稱也以Test結尾。你會發現已經有了一個預設的測試案例。

建立項目後，預設會給我們建立一個和bundle名稱+Tests.m的測試類別，它包含的預設代碼含義如下：

  - (void)setUp {       [super setUp];       // Put setup code here. This method is called before the  invo cation of each test method in the class.      //初始化的代碼，在測試方法調用之前調用}- (void)tearDown {        // Put teardown code here. This method is called after the invocation of each test method in the class.       // 釋放測試案例的資原始碼，這個方法會每個測試案例執行後調用       [super tearDown];}- (void)testExample {           // This is an example of a functional test case.           // Use XCTAssert and related functions to verify your tests produce the correct results.           // 測試案例的例子，注意測試案例一定要test開頭}- (void)testPerformanceExample {         // This is an example of a performance test case.         // 測試效能例子，有Instrument調試工具之後，其實這個沒毛用。         [self measureBlock:^{         // Put the code you want to measure the time of here.         // 需要測試效能的代碼          }];}

 

2.寫一個簡單的測試案例 
在testExample方法中輸入

- (void)testExample {    // This is an example of a functional test case.    // Use XCTAssert and related functions to verify your tests produce the correct results.    NSLog(@"開始愛上單元測試的第一個單元測試測試");    NSString *test = @"這是我的第一個單元測試";    XCTAssertTrue([test isEqualToString:@"初來乍到，就想測試成功，沒門"]);}

 

然後按快速鍵Command + U進行單元測試，這個快速鍵是全部測試。可以看到如下結果介面：

由於我們使用了斷言XCTAssetTrue,它用來比較一個運算式是否為真，顯然這個運算式是返回false的，所以這個測試案例肯定通過不了嘛。

我們也可以點擊播放按鈕，測試某個測試案例。

3.XCTest常見的斷言

XCTFail(format…) 產生一個失敗的測試；XCTAssertNil(a1, format...)為空白判斷，a1為空白時通過，反之不通過；XCTAssertNotNil(a1, format…)不為空白判斷，a1不為空白時通過，反之不通過；XCTAssert(expression, format...)當expression求值為TRUE時通過；XCTAssertTrue(expression, format...)當expression求值為TRUE時通過；XCTAssertFalse(expression, format...)當expression求值為False時通過；XCTAssertEqualObjects(a1, a2, format...)判斷相等，[a1 isEqual:a2]值為TRUE時通過，其中一個不為空白時，不通過；XCTAssertNotEqualObjects(a1, a2, format...)判斷不等，[a1 isEqual:a2]值為False時通過；XCTAssertEqual(a1, a2, format...)判斷相等（當a1和a2是 C語言標量、結構體或聯合體時使用,實際測試發現NSString也可以）；XCTAssertNotEqual(a1, a2, format...)判斷不等（當a1和a2是 C語言標量、結構體或聯合體時使用）；XCTAssertEqualWithAccuracy(a1, a2, accuracy, format...)判斷相等，（double或float類型）提供一個誤差範圍，當在誤差範圍（+/-accuracy）以內相等時通過測試；XCTAssertNotEqualWithAccuracy(a1, a2, accuracy, format...) 判斷不等，（double或float類型）提供一個誤差範圍，當在誤差範圍以內不等時通過測試；XCTAssertThrows(expression, format...)異常測試，當expression發生異常時通過；反之不通過；（很變態） XCTAssertThrowsSpecific(expression, specificException, format...) 異常測試，當expression發生specificException異常時通過；反之發生其他異常或不發生異常均不通過；XCTAssertThrowsSpecificNamed(expression, specificException, exception_name, format...)異常測試，當expression發生具體異常、具體異常名稱的異常時通過測試，反之不通過；XCTAssertNoThrow(expression, format…)異常測試，當expression沒有發生異常時通過測試；XCTAssertNoThrowSpecific(expression, specificException, format...)異常測試，當expression沒有發生具體異常、具體異常名稱的異常時通過測試，反之不通過；XCTAssertNoThrowSpecificNamed(expression, specificException, exception_name, format...)異常測試，當expression沒有發生具體異常、具體異常名稱的異常時通過測試，反之不通過

 

特別注意下XCTAssertEqualObjects和XCTAssertEqual。
XCTAssertEqualObjects(a1, a2, format...)的判斷條件是[a1 isEqual:a2]是否返回一個YES。XCTAssertEqual(a1, a2, format...)的判斷條件是a1 == a2是否返回一個YES。對於後者，如果a1和a2都是基礎資料型別 (Elementary Data Type)變數，那麼只有a1 == a2才會返回YES。

結尾

點到為止，入門就是入門，讓你稍微有個瞭解。就像給你介紹一個美女，我會給她帶朦朧的面紗，等你開個好價錢（點個贊）之後我才會一步一步揭開它的面紗，(bie四聲)著急，好東西就要一點點的看看才有味道嘛。後面我會陸續推出單元測試進階，單元測試實戰，單元測試中的各種技巧等系列的文章。

參考文章：

《Using Unit Tests》

《iOS開發：XCTest單元測試（附上一個單例的測試代碼》

愛上iOS單元測試系列之愛上她就要先瞭解她：單元測試入門