嘗試了一下把TDD用到真正的項(xiàng)目中

willyomg

這次的TDD不是那么嚴(yán)格，我并沒(méi)有先寫測(cè)試用例再寫代碼，而只是把單元模塊寫好之后立即寫單元測(cè)試，同時(shí)注意維護(hù)一套Test Suite，確保單元測(cè)試的覆蓋程度，并作為代碼重構(gòu)后的驗(yàn)收標(biāo)準(zhǔn)。


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

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



不過(guò)，雖然有上面那些問(wèn)題，但我覺(jué)得TDD仍是一條應(yīng)該堅(jiān)持走下去的路。雖然首次開發(fā)時(shí)時(shí)間較短，但由于Test Suite的存在，日后的維護(hù)代價(jià)會(huì)輕很多。


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