由于敏捷開發的流行，TDD的概念近年來在國內被炒得很火，似乎TDD是一個深不可測的東西。
今天在看TDD的文章時，突然有了一個感覺：其實TDD的思想本來就很樸實，反而是我們開發人員一開始就背離了正確的路線和方法。
眾所周知，TDD鼓勵人們在編寫實際的實現代碼之前，就先寫好測試代碼。這一點對大多數程序員來說難以接受，總覺得實現代碼都沒有寫，怎么寫測試代碼啊。其實我覺得這主要是觀念上的誤區和行為的慣性所致。
我們知道，開發商蓋樓盤時都有一個建筑標準，而業主收樓時也有一個收樓標準。這些標準都是在實際的工程開工之前或業主正式入住之前就已經制定好的。正規的開發商會在建筑的過程中嚴格按照建筑標準來衡量自己的樓盤建設質量。看到有不符合要求的就馬上改正。而不是事先不考慮任何的建筑或驗收標準，等到整個樓盤蓋好后再來。
這個道理和TDD是一樣的，在任何工作開始之前，我們都應該先明確制定工作交付的標準。這一點在需求分析文檔中已經明確體現出來了。到了實際編碼階段卻反而變成相反了。沒有了事實的驗收標準，就等于沒有了目標，連自己要做成什么模樣都不知道，才會出現在聯調階段出現眾多的bug而導致返工的情況，另一方面由于沒有了驗收標準，開發人員經常會出現不知道接口如何設計的困惑。
TDD就是要求我們在編碼階段先制定驗收標準，再根據標準來開發。TDD的過程就是根據驗收標準不斷調整優化的過程，確保你始終沿著預定的目標前進，不會到最后變成一“豆腐渣工程”。
同時為了符合測試程序的要求，您的單元必須設計得可以測試，這迫使您設計程序時，考慮到單元的低耦合。
很多時候技術的思想都很樸實，就像OOP那樣，其實OOP本來就來自于日常生活，雖然說做了高層的抽象，但始終可以通過和現實的類比來看到其本質。
-------------------------------------------------------------
生活就像打牌，不是要抓一手好牌，而是要盡力打好一手爛牌。
posted on 2008-01-29 11:36
Paul Lin 閱讀(1386)
評論(1) 編輯 收藏 所屬分類:
Java 工具