轉載地址: http://www.infoq.com/cn/news/2007/09/tdd-discussions
測試驅動開發：衆人關注，討論熱烈
作者 林芷薰 發佈於 2007年9月24日 下午9時9分
近日以JavaEye爲主的技術社區發起了一系列關於測試驅動開發的討論。從討論中可以看出，越來越多的開發者對測試驅動開發表現出濃厚的興趣，一些人已經在實踐中總結出了自己的經驗；但與此同時，各種與測試驅動開發相關的誤解仍然廣泛存在。
在一個題爲“這樣的TDD實踐方式有問題？” 的討論串中，作者hyysguyang講述了自己在面試中遇到的一個問題：以TDD的方式，編寫“將一個句子反轉”的程序。這個看似簡單的例子，卻讓作者 和麪試者產生了很大的分歧，並引發出關於“如何測試驅動開發”和“如何重構”的大量討論。作爲對這個帖子的回覆，gigix在題爲“測試如何驅動開發”的帖子中寫了三個測試案例，分別測試“把句子拆分成單詞”、“反轉一個句子”、“反轉另一個句子”的功能。
隨後的討論圍繞着“TDD和傳統意義上的測試之間的區別”展開。ozzzzzz這樣說道：
測試是測試，測試驅動是測試驅動，別把兩個東西搞混了。說白了測試驅動還是需求驅動，而測試則需要考慮更多的東西。gigix的做法在tdd看來很棒，但是在測試角度看則很不完整。TDD的做法並不是要你在最早就準備好一個完整的測試系統，而是要你通過寫準對需求的測試，也就是針對功能的測試，來因對性的完成你的代碼。這是一個由需求，轉換爲針對測試，再[轉換爲]因對的代碼的過程。
對於並非直接功能需求的“把句子拆分成單詞”的測試案例，gigix的解釋是：
這個測試就是所謂的“設計過程” 我把一個大的問題分解成兩個小的問題，先用測試驅動解決第一個，再用測試驅動解決第二個。
一開始我只考慮怎麼實現。我設計了一個split的功能，所以我給它寫測試，然後實現它。實現完以後，我發現split顯然不應該是 StringReverser的功能，所以我重構它，把它抽取到SentenceSplitter類，並且把對應的測試也搬到 SentenceSplitterTest。這個時候StringReverser的split方法只是一句直接的delegate，所以不需要測試，並 且可以直接inline到reverse方法內部去。
衆所周知，測試驅動開發在大部分企業裏仍然沒有得到實施，更多的開發者還在用觀望、瞭解和學習的態度看待它，一個常見的問題就是“花費時間寫測試是否合算”。在題爲“TDD，想說愛你不容易”的文章裏，作者yananay對實施測試驅動開發的成本和收益做了一個簡單的核算：
一個月下來，我能運行的測試類有140多個……這樣，每次系統改動的時候，我只要把這些測試全運行一次，就知道我負責的模塊是不是有問 題。 那麼其他人呢？他們仍然在手動測試……就算我那140個測試方法都是單獨的，[編寫]每個方法我需要10分鐘， 那麼我需要 1400 分鐘，1400/60 = 23.3 個小時。也就是說，一個月下來，我只需要多付出23.3個 小時。 那麼收益是多大呢？一個月後，我只需要20分鐘就可以知道系統是不是存在錯誤，而他們卻 需要幾個小時，而且未必準確。
James Zhao在討論中對測試驅動開發做了一個很好的總結：
既然是測試驅動，那麼，TDD就和需求關係緊密，至少距離需求比較近，而不是傳統的那些開發過程，測試排在最後。軟件最終由程序員寫代碼實現，所以程序員需要理解需求，實現系統功能，把問題解決在自己的範圍之內，因此是不是測試驅動開發，程序員自己的測試都很重要，而測試驅動開發就更向前走了超前的一步，保障軟件的質量，開發的效率。至於風險，應該說隨着軟件開發方法、開發過程理論實踐的不斷髮展，風險是逐漸下降的，也就是說，使用傳統的開發過程，風險可能會更大。能夠起到多大的作用，提高多少效率，存在多大風險，在於使用TDD的開發者的水平。
在文章的最後，作者yananay毫不掩飾地表達出自己對測試驅動開發的信心：
如果你是一個準備購買軟件的客戶，那麼你可以毫不猶豫地要求軟件開發商使用TDD的方式， 因爲你應該知道這樣做其實是在保護你的利益。如果你是一個老闆，那麼你應該立刻要求下屬學習並實踐TDD，如果客戶不買單，那麼你應該 買單，因爲你應該相信，微小的成本會換來更好的軟件，更好的軟件會迎來更多的客戶。 如果你是一個開發人員，那麼你應該立刻學習並實踐TDD，如果你的客戶和老闆都不準備買 單，那麼就自己買單。你應該相信，微小的付出，會換來更多的價值！
您的看法呢？