嘗試了一下把TDD用到真正的項目中

willyomg

這次的TDD不是那么嚴格，我并沒有先寫測試用例再寫代碼，而只是把單元模塊寫好之后立即寫單元測試，同時注意維護一套Test Suite，確保單元測試的覆蓋程度，并作為代碼重構(gòu)后的驗收標準。


總體上，搞了一段時間之后，我覺得代碼質(zhì)量比較高（Bug率較低），但效率很難讓人滿意，并且我也并不那么快樂。

   1.寫單元測試幾乎成了一種負擔。
        a. 手動生成測試類太辛苦太無聊。不過后來發(fā)現(xiàn)了Fast Code Plugin，情況有所改觀
        b. 寫一個代碼立即寫一個測試類，不符合批量作業(yè)的原理：你的頭腦要不停地從開發(fā)者到測試者兩者之間切換，效率低下，而且很讓人沮喪；當重構(gòu)發(fā)生時，單元測試也要重構(gòu)，這更加讓人不勝奇煩。后來我想的辦法是先把一定的代碼全部寫好之后寫測試來測，為了不遺漏，我會在寫代碼時做個標記(比如throw UnsupportedOperationException)，然后在測試時按這些標記找到應測類。
        c.單元測試不是那么好寫。我的經(jīng)驗發(fā)現(xiàn)單元測試的代碼量往往會超過被測代碼。比如說，EasyMock的三步曲還是不夠簡潔，用JAVA寫測試數(shù)據(jù)也挺麻煩。最終我發(fā)現(xiàn)，單元測試使開發(fā)周期加倍。
   
   2.TDD提倡的自底向上的設計思路也會搞得很低效。 自底向上的設計，即先寫代碼再重構(gòu)，的確可以讓你的腦子免于很多思考，先把車開到山前，到了山前再開路。但我的體會就是“山前開路”發(fā)生的太頻繁了，而且“返工”太多了。9點開好的一條臨時小徑，11點就得被重構(gòu)掉，加上它的測試用例，再考慮到CVS等因素，反復重構(gòu)非常低效。 所以我后來覺得，還是先設計為好。



不過，雖然有上面那些問題，但我覺得TDD仍是一條應該堅持走下去的路。雖然首次開發(fā)時時間較短，但由于Test Suite的存在，日后的維護代價會輕很多。


原文http://www.javaeye.com/topic/480096