測試驅動開發到底好不好

愛飛翔發表於2011-10-21

  很長時間沒有自己寫部落格了,前兩個月看了一些關於測試驅動開發(Test-Driven Development, 簡稱TDD)和敏捷軟體開發(Agile Software Development)是否有用、是否一定得用的爭論,很精彩,也很引人思考。尤其感謝酷殼網的站長陳皓先生將這些觀點蒐羅起來並發表了自己的看法。

  在我的同事(尤其是小利)面前,我一直裝著是個敏捷的忠實粉絲,但是嚴格的來講,任何一種開發方法學都不能強制地推廣到所有開發者的身上。一個磨合良好的團隊應該以人為出發點,而不是以規則。不同風格的開發者在一系列鬆散的規則下互相磨合的工作,才是健康的一個開發迴圈。

  我很難相信,有很多沒有做過專案甚至不曾鑽研技術的人去做敏捷諮詢師。儘管一直很想做技術諮詢業,但是一直對這個敏捷培訓行業沒有太多深入的瞭解。有朋友如果對敏捷諮詢這種行業有自己的見解,那麼我是急於認識的。

  敏捷軟體開發那個話題太大,尤其是非技術面的觀點融入進來之後,容易變成清談,所以今天先不提。著重說一下對測試驅動開發的看法。TDD存在的主要問題就是,如果需求不是很明確,或者需求提出方變動特別頻繁,那麼回導致測試程式碼頻繁的變更,從而減緩甚至干擾工程進度。還有就是特定開發人員的思維與TDD的流程磨合不融洽。所以並不是一定要強制進行TDD。測試並行、測試後行都是可以被接受的。但是應當給全體團隊講授TDD思想和技術,因為其中一些特定細節,比如邊界值檢測,按契約程式設計,前條件、後條件測試,對於非TDD測試照樣可用。

  相比強制推行TDD而導致的低效,另外兩種做法則是更不能容忍的。一種是等程式碼邏輯全部完成之後,匆忙補寫測試用例,並且只測試想當然的情境,得出 “果然成立”的結論後,就匆忙提交了。例如寫一個ArrayList,測試了add(Object)方法前後的size大小是否差1,就認為add方法實 現正確了,根本不管add(null)或者多次add同一個引用時是否結果正確。這種態度就是事先擬定了一個“正確”的路徑,然後沿著這個路徑草草寫就一個測試用例,不管其它路徑。是一種不負責任的態度。質量管理人員或者團隊成員有義務阻攔這種程式碼進入程式碼庫。如果因為工期的關係必須出產品,那麼官方的主幹版本也絕不應該允許這種程式碼入庫,至多隻能提交到beta分支上。待原作者補完合格的測試後,再行併入主幹。

  另一種則是根本不進行任何測試,等待一個集中的時間補寫,例如產品3.0版本釋出後抽出一週專門補寫。這種規劃基本是精神勝利法式的管理。自認為測試已經在精神上被“寫完備了”,只是沒落到程式碼上而已。然而在實際的工程裡,根本不會有任何人再去補寫這部分測試了,所有人會立刻投入下一個版本或產品的開發中去。

  比較穩妥的辦法是當程式碼主路徑及一些支流路徑初具規模時即開始著手規劃測試,然後通過測試來完善程式碼流程中的疏漏,同時根據程式碼流程的變化(可能是需 求變更引發的)來更新測試用例。這時程式碼和測試基本處於穩定狀態,管理起來也比TDD風險小很多了。總之,團隊成員的測試警覺度和技術管理者對測試程式碼質量的高要求可以淡化TDD的強制性,作出一種柔性測試的氛圍。這對於團隊的磨合是有益處的。

  關於如何寫好測試的問題,我閱讀還不是很深入,初步可以肯定有價值的資料除了Kent Beck的《測試驅動開發》,還有Gerard Meszaros的《xUnit Test Patterns : Refactoring Test Code》。後者是一本字典式的參考書,可選讀。也歡迎發現有價值的JUnit等單元測試參考書的朋友及時告知。

相關文章