測試驅動開發——讀《浮現式設計》有感

        題記：正在讀《浮現式設計:專業軟體開發的演化本質》(榮獲第19屆Jolt生產力大獎)一書，順手寫下了一點自己的感想與淺見，是以為記。

 

        前幾天剛在我的微博上說我在讀一本《測試驅動開發》的書，今天在讀《浮現式設計》時又遇見了“測試驅動開發”，好友胡研還調侃說現在有需求驅動開發、系分驅動開發、文檔驅動開發、模型驅動開發、用例驅動開發、專案管理驅動開發、品質驅動開發等各種驅動開發。開發人員很悲催呀，各種被驅動:-(

        回到測試驅動開發上來吧，當然不是測試人員驅動開發人員，而是用測試的思路推動代碼的實現，針對的是開發人員一個角色，通過先寫測試代碼再寫產品代碼的方式完成開發活動的一種方法。簡稱TDD。

        我個人與作者一樣，一直對這個方法持有懷疑態度，也從來沒有付諸於實踐。我也曾認為測試是一個專業的活動，應由專門的人員（測試工程師）或部門（品質保證部）來實施方能得到更大的收益。本來開發人員就沒時間，還怎麼去再做測試的活呢？

        現在，我依然沒有採用這種進階的實踐方式，也沒能轉換到這種思考問題的方式上，但測試的作用我是認同的。

        還記得幾章前的軟體品質中提到的內聚、耦合與冗餘嗎？

        內聚強的類更易於測試。內聚強也是單一職責原則的體現，當一個類只有單一職責時，無論是先構造測試還是後構造測試，測試代碼都會簡潔高效，同時這種測試代碼也可以扮演用戶端的角色，測試代碼對類的使用方式，其實就是該類交付後用戶端代碼的調用方式，具有天然的demo功能，也是對文檔的有效補充。

        耦合度高的對象難於測試。耦合度高的對象，相互之間關係複雜，甚至於牽一髮而動全身，測試案例不好構造，不好隔離，出了問題仍然不好分析定位。還要引入Stub、Mock、Fake等額外的手段來輔助測試案例的構造。如果出現這種情況，其實也在某種程度上說明存在設計不當或設計過度的可能，也許要重構了。

        測試為檢驗冗餘提供了機會。無論是使用複製粘貼的代碼，還是複用並少量修改了前人的代碼，還是通過其他途徑，隨著時間的推移，系統中總會出現更多的易被忽視的冗餘，我曾在《架構如何才能抵制熵增》一文中有專門的描述，使用測試，如果出現冗餘的測試，很有可能就有冗餘的代碼，這個是利於檢測代碼冗餘的。

        對於測試驅動開發而言，完全具有測試的作用，編寫測試，或者考慮如何編寫測試，實質上都是以代碼的方式在思考。這對代碼的可測試性尤其有利。但TDD的實施肯定有一些條件，重要的不是先寫測試還是後寫測試，也不是糾結於要不要實施TDD，而是把對代碼的可測試性的要求作為衡量代碼品質的日常指標，從而引導開發人員擁抱測試。這個過程會漫長且煎熬，有人說像面向過程思維轉向物件導向思維一樣，但轉換成功後，一定會有他的價值的。

——歡迎轉載，請註明出處 http://blog.csdn.net/caowenbin ——