依賴屬性之“風雲再起”二五. 引入測試驅動開發

　　由于本篇的依賴屬性體系是基于測試驅動開發完成的，是以我們就先來看一下什麼叫測試驅動開發：測試驅動開發的基本思想就是在開發功能代碼之前， 先編寫測試代碼。也就是說在明确要開發某個功能後，首先思考如何對這個功能進行測試，并完成測試代碼的編寫，然後編寫相關的代碼滿足這些測試用例。然後循 環進行添加其他功能，直到完全部功能的開發。由于過程很長，在寫的時候也省略了不少步驟，是以有些地方銜接不是那麼的流暢，對此表示非常的抱歉！

根據自身做項目使用TDD的一點微薄經驗，總結了以下幾個注意事項：

◆ 找準切入點： 　　不論是開發一個新的系統還是複原系統，都必須先找準一個或多個切入點，從切入點經曆”測試代碼－功能代碼－測試－重構“來逐漸完善整個系統，往往這個切入點就是功能點，就是這個系統具備哪些功能，然後根據這些功能寫出測試用例。 ◆ 測試清單： 　　大家都知道一個系統或者一個架構都是很龐大的，如果要引入測試驅動開發，首先我們必須要有一個測試清單，在任何階段想添加功能需求問題時，把相 關功能點加到測試清單中，然後繼續開發的工作。然後不斷的完成對應的測試用例、功能代碼、重構。這樣可以避免疏漏的同時也能把控目前的進度。 ◆ 測試驅動： 　　這個比較核心。完成某個功能，某個類，首先編寫測試代碼，考慮其如何使用、如何測試。然後在對其進行設計、編碼。這裡也強調先編寫對功能代碼的判斷用的斷言語句，然後編寫相應的輔助語句。 ◆ 良好的代碼設計及可測性： 功能代碼設計、開發時應該具有較強的可測試性。應該盡量保持良好的設計原則和代碼規範，如盡量依賴于接口、盡量高内聚、低耦合等等。 ◆ 子產品或功能隔離： 　　不同代碼的測試應該互相隔離。對一塊代碼的測試隻考慮此代碼的測試，不要考慮其實作細節，不然就會陷入一團亂麻之中，這個可以通過MOCK來實作，同時在開始的時候也要劃分好邊界。 ◆ 适當引入MOCK： 　　在适當情況下引入MOCK來完成單元測試，這種情況尤其是在邊際互動比較多的案例當中，對于互動比較多且複雜的多個類關系可以用MOCK暫時模拟，這是一個不錯的解決方案。 ◆ 由小到大、由偏到全、統籌兼顧： 　　一個産品或者一個項目是比較大的，是以我們這裡就需要遵循由小到大、由偏到全、統籌兼顧的原則，分解功能和代碼。把所有的規模大、複雜性高的工作，分解成小的任務來完成，這樣既友善團隊協作，同時也減輕了複雜度，使整個開發一下子變得簡單了許多。 ◆ 保持随時重構的習慣： 　　很多開發者在經過測試代碼－功能代碼－測試通過以後就當完成了任務，其實你會發現随着其他功能的引入或者使用過程中發現了很多重複、備援的代 碼、再或者先前的代碼結構和設計不太合理，這個時候就需要随時的進行重構和單元測試，在一方面可以避免産生風險，另一方面可以使系統更加完善。 ◆ 随時進行回歸： 　　在”測試代碼－功能代碼－測試－重構“的循環中一定要記住多回歸，因為這樣可以保證目前的代碼是不是會影響到前面的功能，其實隻需要看看紅綠燈就行。 ◆ 檢視和統計代碼覆寫率： 　　通過前面的步驟之後，我們就要看一下實作的功能是否達到我們的預期目标，除了功能完善之外，還要保證代碼的覆寫率，因為它是一個系統穩定與否、可維護性與否的一個重大标志。

這個工具使用

本文轉自KnightsWarrior51CTO部落格，原文連結：http://blog.51cto.com/knightswarrior/405230，如需轉載請自行聯系原作者