測試驅(qū)動開發(fā)：中文版

　　代碼整潔可用（clean code that works），Ron Jeffries這句言簡意賅的話，正是測試驅(qū)動開發(fā)（TDD）所追求的目標(biāo)。代碼整潔可用之所以是一個值得追求的目標(biāo)，是基于以下的一系列原因：§ 它是一個可預(yù)測的開發(fā)方法。你知道什么時候可以完工，而不用去擔(dān)心是否會長期被bug困擾?！?它給你一個全面正確地認(rèn)識和利用代碼的機(jī)會。如果你總是草率地利用你最先想到的方法，那么你可能再也沒有時間去思考另一種更好的方法?！?它改善了你的軟件用戶的生活§ 它讓軟件開發(fā)小組成員之間相互信賴§ 這樣的代碼寫起來感覺很好但是我們要怎樣做才能使代碼整潔可用呢？很多因素妨礙我們得到整潔的代碼，甚至是可用的代碼。無需為此征求很多的意見，我們只需用自動運行的測試來推動開發(fā)，這是一種被稱之為測試驅(qū)動開發(fā)的開發(fā)方式（TDD）。在測試驅(qū)動開發(fā)中，我們要這樣做：§ 只有自動測試失敗時，我們才重寫代碼§ 消除重復(fù)設(shè)計，優(yōu)化設(shè)計結(jié)構(gòu)這是兩條很簡單的規(guī)則，但是由此產(chǎn)生了復(fù)雜的個人和小組行為規(guī)范，技術(shù)上的含意是：§ 我們必須通過運行代碼所提供的反饋來做決定，并以此達(dá)到有機(jī)設(shè)計的目的?！?我們必須自己寫測試程序，這是因為測試很多，很頻繁，我們不能每天把大量的時間浪費在等待他人寫測試程序上§ 我們的開發(fā)環(huán)境必須能迅速響應(yīng)哪怕是很小的變化§ 為使測試簡單，我們的整個規(guī)劃必須是由許多高內(nèi)聚、低耦合的部分組成這兩條規(guī)則實際上蘊含了開發(fā)過程中所經(jīng)歷的階段：§ 不可運行──寫一個不能工作的測試程序，一開始這個測試程序甚至不能編譯§ 可運行──盡快讓這個測試程序工作，為此可以在程序中使用一些不合情理的方法§ 重構(gòu)──消除在讓測試程序工作的過程中產(chǎn)生的重復(fù)設(shè)計，優(yōu)化設(shè)計結(jié)構(gòu)不可運行/可運行/重構(gòu)──這就是測試驅(qū)動開發(fā)的口號現(xiàn)在假設(shè)這樣的開發(fā)方式是可能的，那么，進(jìn)一步，顯著地減少代碼的錯誤密度（defect density），讓所有參與某一工作的開發(fā)人員對工作主題足夠明了的假定也將成為可能。如果是這樣的話，那么只有測試失敗時才需要重寫代碼，其社會意義是：§ 如果代碼的錯誤密度能夠充分地減少，那么軟件的質(zhì)量保證（QA）工作可以由被動保證軟件質(zhì)量轉(zhuǎn)變?yōu)橹鲃颖ＷC軟件質(zhì)量§ 如果開發(fā)過程中令人不快的意外能夠充分地減少，那么項目經(jīng)理能對軟件開發(fā)進(jìn)度有一個精確的把握，以讓實際用戶參與日常開發(fā)§ 如果每次技術(shù)討論的主題都足夠明確，那么軟件工程師之間的合作是以分鐘計算的，而不是每天合作或每周合作§ 再者，如果代碼錯誤密度能夠充分地減少，我們每天都可以得到有新功能的軟件成品（shippable），并以此產(chǎn)生新的商業(yè)關(guān)系如此說來，觀念是很簡單的，但我的動機(jī)是什么呢？為什么一個軟件工程師要做額外的寫自動測試程序的工作？為什么一個設(shè)計觀念可以瞬息萬變的軟件工程師卻只能一小步一小步地進(jìn)行工作？我們需要的是勇氣。勇氣測試驅(qū)動開發(fā)是一種可以在開發(fā)過程中控制憂慮感的開發(fā)方法。我并非指那些毫無意義的沒有必要的擔(dān)憂──（pow widdle prwogwammew needs a pacifiew）──而是指合理的擔(dān)憂，擔(dān)憂是否合理是個很困難的問題，不能從一開始就看出來。如果說疼痛自然就會叫 "停！"，那么擔(dān)憂自然就會說"細(xì)心！"，小心謹(jǐn)慎是好的，但它也會產(chǎn)生以下一系列負(fù)面影響：§ 讓你一直處于試驗性的階段。§ 讓你不愿意與他人交流?！?讓你羞于反饋。§ 讓你變得脾氣暴躁。這些負(fù)面影響對編程都是有害無益的，尤其是當(dāng)需要編程解決的問題比較困難的時候。所以問題變?yōu)楫?dāng)我們面臨一個比較困難的局面的時候，如何才能做到：§ 盡快開始具體的學(xué)習(xí)，而不是一直處于試驗性的階段。§ 更多地參與交流和溝通，而不是一直拒不開口§ 尋找那些有益的、建設(shè)性的反饋，而不是盡量避免反饋§ （依靠自己改掉壞脾氣）設(shè)想把編程看成是轉(zhuǎn)動曲柄從井里提一桶水上來的過程。如果水桶比較小，那么僅需一個能自由轉(zhuǎn)動的曲柄就可以了。如果水桶比較大而且裝滿水，那么還沒等水桶全部被提上來你就會很累了。你需要一個防倒轉(zhuǎn)的裝置，以保證每轉(zhuǎn)一次可以休息一會兒。水桶越重，防倒轉(zhuǎn)的棘齒相距越近。測試驅(qū)動開發(fā)中的測試程序就是防倒轉(zhuǎn)裝置上的棘齒。一旦我們的某個測試程序能工作了，你就知道，它從現(xiàn)在開始并且以后永遠(yuǎn)都可以工作了。相比于測試程序沒有通過，你距離讓所有的測試程序都工作又近了一步。現(xiàn)在我們的工作是讓下一個測試程序工作，然后再下一個，就這樣一直進(jìn)行。分析表明，要編程解決的問題越難，每次測試所覆蓋的范圍就應(yīng)該越小。我的《Extreme Programming Explained》一書的讀者可能會注意到我講極限編程（XP）與講測試驅(qū)動開發(fā)的語氣是有區(qū)別的：講測試驅(qū)動開發(fā)不像講極限編程那么絕對。講極限編程時我會說"這些是想進(jìn)一步學(xué)習(xí)所必須具備的基礎(chǔ)"，而講測試驅(qū)動開發(fā)時要模糊一些。測試驅(qū)動開發(fā)知道編程過程中的反饋與欲實現(xiàn)的構(gòu)思之間的差距，并且提供了控制這個差距大小的技術(shù)。"如果我在紙上規(guī)劃一周，然后通過測試驅(qū)動編碼，這是否就是測試驅(qū)動開發(fā)？"當(dāng)然，這就是測試驅(qū)動開發(fā)。你知道欲實現(xiàn)的構(gòu)思與反饋之間的差距，并且有意識地控制了這個差距。絕大多數(shù)學(xué)習(xí)測試驅(qū)動開發(fā)的人發(fā)現(xiàn)他們的編程習(xí)慣被永久地改變了。"測試感染"（Test Infected）是Erich Gamma所杜撰的用以描述這種轉(zhuǎn)變的詞語。你可能發(fā)現(xiàn)寫測試程序變得容易了，并且相對較小的工作節(jié)奏比前所夢想的節(jié)奏更明智。另一方面，一些學(xué)習(xí)測試驅(qū)動開發(fā)的軟件工程師重回到了以前的程序開發(fā)方法，而保留測試驅(qū)動開發(fā)方法作為當(dāng)其它開發(fā)方法不能奏效的特殊情況下的秘密武器。當(dāng)然也存在一些編程任務(wù)不能僅僅（或者根本就不能）由測試程序來驅(qū)動開發(fā)。舉個例子來說，軟件的安全性和并行性，測試驅(qū)動開發(fā)方法就不能充分地從機(jī)械證明的角度說明軟件是否達(dá)到這兩個目標(biāo)。軟件安全性從本質(zhì)上來說依賴于無缺陷的代碼。確實如此，但它同時也依賴于人們對軟件安全機(jī)制的判斷。精妙的并行問題不是僅靠再次運行代碼就能可靠地重復(fù)出現(xiàn)的。一旦你讀完本書，你要準(zhǔn)備：§ 從簡單的例子開始?！?寫自動測試程序?！?重構(gòu)，每次增加一個新的設(shè)計構(gòu)思。這本書是由三個部分組成的：§ 第一部分，資金實例（The Money Example）── 一個典型的完全由測試驅(qū)動的代碼模型的例子。這個例子是幾年前我從Ward Cunningham那兒得到的，并且自從引入多幣種算法以來已經(jīng)多次用到過。你將從中學(xué)會如何在寫代碼之前寫好測試程序，并最終發(fā)展成為一個有機(jī)的規(guī)劃方案§ 第二部分，xUnit實例（The xUnit Example）── 一個通過建立自動測試框架來測試包含映像（reflection）和異常（exception）的邏輯上更復(fù)雜的程序的例子。這個例子同時也將向你介紹作為許多面向程序員的測試工具靈魂的xUnit結(jié)構(gòu)體系。在第二個例子中你將學(xué)會以甚至比第一個例子更小的開發(fā)步驟工作，同時也包括深受許多計算機(jī)專家喜愛的呼喊式的自我提醒（self－referential hooha）?！?第三部分，測試驅(qū)動開發(fā)模式（Patterns for Test-Driven Development）──包括決定寫哪些測試的模式，如何用xUnit寫測試的模式和大量的設(shè)計模式精選以及例子中所用到的重構(gòu)。我寫了關(guān)于結(jié)對編程（pair programming）的例子。如果你習(xí)慣于在四處轉(zhuǎn)一轉(zhuǎn)之前先看一看地圖的話，你可以直接到第三部分去看那些模式，并將那些例子作為說明。如果你習(xí)慣于先到四處轉(zhuǎn)一轉(zhuǎn)，然后再看地圖以確定自己處于什么位置的話，試著通讀例子，當(dāng)你需要了解更多關(guān)于某一技術(shù)問題的細(xì)節(jié)時，可以查閱后面所講的模式，并將這些模式作為參考。一些批評家指出，當(dāng)他們啟動編程環(huán)境，輸入代碼，運行所讀到的測試程序時，最大的收獲卻在這些例子之外。關(guān)于這些例子要注意一點。這兩個例子，多幣種計算和測試框架，顯得很簡單。而解決同一個問題卻也存在（我曾經(jīng)見到過）一些復(fù)雜、風(fēng)格很差、近乎弱智的解決方案。我本可以從這些復(fù)雜、風(fēng)格很差、近乎弱智的解決方案中采用一個以使本書有一種"真實"感。然而，我的目標(biāo)是寫出整潔可用的代碼，希望你的目標(biāo)也是這樣。在以那些被認(rèn)為很簡單的例子開始之前，花15秒的時間設(shè)想一下，如果所有的代碼都能如此清晰和直接，沒有復(fù)雜的解決方案，只有顯然需要認(rèn)真思考的很復(fù)雜的問題，那么這個世界會是什么樣子。測試驅(qū)動開發(fā)可以引導(dǎo)你這樣去認(rèn)真思考。

　　Kent Beck是軟件開發(fā)方法學(xué)的奉斗、XP的創(chuàng)始人，長期致力于軟件工程的理論研究和實踐，并具有講授XP的豐富經(jīng)驗，作為軟件業(yè)內(nèi)最富創(chuàng)造性和最有口碑的領(lǐng)導(dǎo)人之一，Kent Beck極力推崇模式、極限編程和測試驅(qū)動開發(fā)。他現(xiàn)在加盟于Three Rivers研究所，是多部暢銷書如《Smalltalk Best Practice Patterns》、《解析極限編程——擁抱變化》和《規(guī)劃極限編程》（和Martin Fowler合著）的作者，并且是超級暢銷書《重構(gòu)——改善既有代碼的設(shè)計》（中國電力出版社出版中英文版）的特約撰稿人。