iOS開發進階之單元測試(3)

　　實踐6：運用自上而下的方式構建類。

　　解釋：自上而下的方式可以使類的功能明確，類的構成將會清晰緊湊，不會出現一些廢方法。

　　先確定類需要負擔的責任，以此來確定類具有的公有方法以及屬性。通過重構將公有方法中的代碼轉化為私有方法，以使方法盡量短小緊湊。

　　實踐6.1：應對所有暴露的屬性和方法提供測試，私有方法則不必。

　　解釋：如果運用自上而下的方式構建類，則理論上私有方法應該都是公有方法重構而得到的。實際上測試公有方法時這些私有方法都應該被測試到了。而且，由于私有方法相對公有方法來說發生變動的可能性很大，會造成不必要的修改測試代碼的成本。

　　回調方法不屬于私有方法，也需要進行測試。

　　實踐6.2：回調方法的測試方法是直接調用。

　　解釋：基本功

　　由于回調方法一般是異步和不可觸發的(按正常流程)，例如網絡事件的返回和按下按鈕的觸發事件。因而，測試的時候要直接調用來對其流程進行檢測。例如某個按鈕的touch up inside事件：

　　-(void)buttonPressed:(id)sender;

　　可以根據方法中用到的方法、屬性偽造一個FakeButton按鈕作為參數傳遞進行測試。

　　實踐6.3：測試私有的方式，KVC、子類化和類別。

　　解釋：基本功。

　　遇到需要通過驗證私有數據才能編寫的測試時，可以考慮使用KVC和子類化。子類繼承于被測類，只包含于單元測試target，其作用就是在不該變受測類的情況下，使受測類具有某些易于被測的能力。

　　實踐7：變化需要新測試的支持。

　　解釋：保證測試的覆蓋度。

　　就像敏捷中提到的“改變需要抽象”一樣，在測試中改變需要新的測試。當然，度依然由程序員自己掌控。

　　四、一般流程

　　使用OCUnit最大的好處就是流程非常的簡單，簡單到讓你覺得非常愉悅。由于有XCode的支持，添加測試變得異常簡單。只要在新建工程時勾選“Include Unit Tests”，就會自動的加入一個示例。然后再需要添加新的單元測試時，新建一個“Objective-C test case class”就可以了。

　　測試文件中，只要知道setUp是初始化的地方，tearDown是結束清理的地方，而且它們在每個用例方法執行時都會重新執行--這保證了測試用例的原子性。然后知道每個測試用例都是以test作為前綴的，并且無返回值。然后在方法中編寫斷言語句就可以了。輸入STAssertxxxxx就可以看到它們的聯想提示。編寫完成后，執行菜單 Product->Test，單元測試就完成了!

　　五、測試驅動(TDD)

　　敏捷當中提到了TDD這種開發方式。TDD的主旨是使開發者對其編寫的代碼更有信心，使開發者修改代碼時心里更加踏實。對于其總結，還是引用原文比較妥當：“測試驅動開發的妙處即在于，它以需求為引領，通過測試的形式，來指導開發者進行軟件的設計與架構，并編寫出最為精煉的代碼，使得測試用例運行通過。經過適當的重構之后，測試用例與產品代碼可達到較為健康的狀態。”也就是上面提到的，通過自上而下的形式設計類，通過單元測試來不停地審視和重構類，從而達到代碼的健康。

　　如果在代碼寫完之后在編寫單元測試，那么就體現不出這種模式的好處了。這就好像寫完代碼再補文檔一樣，沒有什么意義。測試應該在代碼開始之前，或者在代碼編寫中不停地進行編寫更新，這樣才能使代碼不停進步。這也正是TDD的意思。

　　六、總結

　　單元測試的代碼如此簡單，但是想寫好單元測試卻并不是一件簡單的事情。它需要程序員比較深的功底。由于個人水平所限，有一些東西說的比較啰嗦。把復雜問題簡單化是本事，任重而道遠。希望大家可以在日常開發中運用好這種簡潔高效的技術。

原文轉自：http://www.uml.org.cn/Test/201306072.asp