摘要：在軟件行業中，神仙打架的名場面，那就不得不提的是2014年的那場——測試驅動開發（TDD）之爭。
在歷史上有不少精彩絕倫的神仙打架，好比數學界的牛頓和萊布尼茨關於微積分的曠世之爭；好比量子物理中的愛因斯坦和波爾的紫禁之巔；好比足球裏的梅西和C羅的旗鼓至關難分高下；又好比滴滴和快滴之間觸目驚心的燒錢大戰……而在軟件行業中，也一樣有神仙打架的名場面，那就不得不提的是2014年的那場——測試驅動開發（TDD）之爭。程序員
比賽的紅方是David Heinemeier Hansson，藍方是Kent Beck。David Heinemeier Hansson 因爲名字較長簡寫成DHH，Ruby on Rails 正是出自於DHH之手。而這場打架還加入了「裁判」員——Martin Fowler，在比賽中Martin Fowler記錄了紅藍雙方的每一次組合拳、上勾拳、側踹、抱摔……總結以下：編程
紅方DHH觀點：
- 許多推進TDD的開發人員會讓你以爲：若是你不使用TDD的話，你的代碼就是骯髒的。
- 由單元測試開始驅動你的設計並非一個好的主意。
- TDD的概念「測試必須夠快」是目光短淺的。
- 對TDD的依賴會致使完全忘記系統測試。
- 關注而且只關注單元模塊並不能有助於建立一套完美的系統。
- 100%的覆蓋率是愚蠢的。
- 程序員但願軟件是一門科學，但是它並非。它更像是創造性的寫做活動。
- 優秀的軟件並不像工程學那樣，它更像寫做。清楚簡潔的寫做要優於複雜晦澀的寫做。
- 清晰是有好處的，好到應該將清晰性做爲第一目標，而非測試覆蓋度或者測試速度。
- 成爲一名優秀的開發人員就像成爲一名優秀的做家同樣困難。
- 就像寫做同樣，成爲優秀的程序員的辦法就是以清晰爲目標從而大量編寫軟件、大量閱讀軟件。
藍方Kent Beck觀點：
DHH已將TDD委託給歷史垃圾堆。我很難過，不是由於我就把它從歷史的垃圾堆中拯救出來，而是由於如今我須要僱傭新技術來幫助我解決編程過程當中的許多問題：設計模式
- 過分工程化。我傾向於「投入」我「知道」我「將須要」的功能。使一個紅色的測試變爲綠色（以及將來的測試列表）有助於我實現足夠的功能。我須要找到一個新的方法來保持專一。
- API反饋。我須要找到一種新的方法來得到關於個人API決策的快速反饋。
- 邏輯錯誤。我須要找到一種新的方法來抓住那些我很容易犯的討厭的測試錯誤。
- 文檔。我須要找到一種新的方式來傳達我對api的指望，並記錄我在開發過程當中的想法。
- 感到不知所措。我真的會懷念如何使用TDD，即便我沒法想象一個實現，我幾乎總能想出如何編寫測試。我須要找到一個新的方法，以便下一步上山。
- 將接口與實現思想分離。我傾向於用實現推測來污染API設計決策。我須要找到一種新的方法來分離這兩個層次的思惟，同時在它們之間提供快速的反饋。
- 協議。我須要找到一個新的方法，精確地與一個編程夥伴關於我正在解決的問題。
- 焦慮。也許我最懷念的是TDD給個人瞬間「一切都好嗎？」按鈕。
- 我相信我會找到其餘方法來解決這些問題。及時。疼痛會減輕的。再見TDD，老朋友。
神仙打架不虧是神仙打架，從那之後業界關於測試驅動開發的觀念也分紅了兩派。一派主要來源自像國內的一些互聯網等項目中聲音——需求的迭代和更新之快，要求公司或團隊能快速交付有價值的產品，而TDD對於不少開發人員來講無疑是帶來了繁重的工做壓力和交付壓力。甚至有人開玩笑話說：「 Deadline Driven Development 纔是第一輩子產力 」。api
固然也有人力挺TDD，「TDD並無死。很明顯，既然它有這麼這麼多的支持者，它怎麼可能會死呢? 這就像在問，設計模式死了嗎？或者功能性自動化死了嗎？不，它並無死。並且它在未來任什麼時候候都不會死亡。它未來可能會變成其餘一些新的事物、甚至是一些更好的事物，可是它永遠不會死亡。因此讓咱們跳過這一部分吧。」函數
關於測試驅動開發說了這麼久，那麼測試驅動開發究竟是個啥呢？單元測試
測試驅動開發（TDD）是什麼
測試驅動開發，英文全稱Test-Driven Development，簡稱TDD，是一種不一樣於傳統軟件開發流程的新型的開發方法。 它要求在編寫某個功能的代碼以前先編寫測試代碼，而後只編寫使測試經過的功能代碼，經過測試來推進整個開發的進行。 這有助於編寫簡潔可用和高質量的代碼，並加速開發過程。學習
Kent Beck：「測試驅動開發不是一種測試技術。它是一種分析技術、設計技術，更是一種組織全部開發活動的技術」。測試
分析技術： 體如今對問題域的分析，當問題尚未被分解成一個個可操做的任務時，分析技術就派上用場，例如需求分析、任務拆分和任務規劃等，《實例化需求》這本書能夠給予必定的幫助做用。url
設計技術： 測試驅動代碼的設計和功能的實現，而後驅動代碼的再設計和重構，在持續細微的反饋中改善代碼。spa
組織全部開發活動的技術： TDD 很好地組織了測試、開發和重構活動，但又不只限於此，好比實施 TDD 的前置活動包括需求分析、任務拆分和規劃活動，這使得 TDD 具備很是好的擴展性。
測試驅動開發（TDD）的目標
Kent Beck 在他的著做《Test-Driven Development》（見參考附錄）一書中提到：「代碼簡潔可用這句言簡意賅的話，正是 TDD 所追求的目標」。
對於如何保證「代碼簡潔可用」可使用分而治之的方法，先達到「可用」目標，再追求「簡潔」目標。
可用： 保證代碼經過自動化測試。
代碼簡潔： 在不一樣階段人們對簡潔的理解程度也不同，不過遵循的原則差很少，例如 OOD 的 SOLID 原則（詳見參考附錄），Kent Beck 的 Simple Design 原則（詳見參考附錄）等。
雖然有不少因素妨礙咱們獲得整潔的代碼，甚至可用的代碼，無需徵求太多意見，只須要採用 TDD 的開發方式來驅動出簡潔可用的代碼。
測試驅動開發（TDD）的規則
在TDD 的過程當中，須要遵循的三項原則：
- 在編寫好失敗的單元測試以前，不要寫任何產品代碼。
- 只要有一個單元測試失敗了，就不要再寫測試代碼。沒法經過編譯也是一種失敗。
- 產品代碼剛好可以讓當前失敗的單元測試成功經過便可，不要多寫。
測試驅動開發（TDD）的流程
測試驅動開發是一個過程，依賴於不斷重複極短的開發週期，這個週期也稱爲「紅燈-綠燈-重構」，如上圖。簡單的來講，基於TDD的三項原則，TDD的這種步驟（週期）以下：
- 添加一個小的測試
- 運行測試並查看失敗
- 對測試進行微小的改動經過測試
- 運行全部測試並看到其經過
- 經過重構去掉重複部分
須要注意的是，不一樣階段有不一樣的目的，他們須要不一樣的解決方案，前二個階段須要很快地完成，以便知道新添加功能的狀態。爲了達成這個目的，能夠經過任何手段，由於僅在這時才這樣作，也是爲了能快速完成好的設計。
測試驅動開發（TDD）的好處
TDD主要的好處主要包括了，肯定性、重構代碼、單元測試即文檔。
肯定性。TDD提高了單元測試的覆蓋率，在每輪迭代產品都會新增代碼，若是有一套覆蓋率很高（ 90% 或更高）的單元測試，那麼只需執跑一遍測試用例，那麼能成功交付的把握就會比較大。反之，若是覆蓋率越低，越須要更多的人力去進行手動驗證。 在 kent Beck的《測試驅動開發》舉的例子中，正因有了TDD纔有勇氣和老闆說咱們能夠作！這就是TDD最強大的地方，它讓你擁有一套值得信賴的測試，打消你對修改代碼的恐懼。
重構代碼。Martin Flower在他的《重構》中也指出，完善的單元測試是他進行重構的基石，從TDD的流程能夠看到，重構是TDD的一部分，運用TDD的同時也推進了代碼的重構。
單元測試即文檔。在軟件行業裏，人員的變更的很頻繁的，若是要儘快熟悉某個模塊的業務邏輯。看文檔？程序員寫的文章通常都不太容易看，並且文檔常常會和代碼不一樣步，代碼修改了文檔沒跟着改的事情常常發生。看源碼？看完也不必定知道爲何。若是這時候有一套很是完整的單元測試，那可能就是全部接手別人代碼的程序員的福音。首先，代碼不會撒謊，其次，測試用例明確告訴了你這個函數是作什麼的，什麼輸入對應的都有什麼預期輸出。單元測試就是最好的底層文檔，哪一個專業人士不想提供這樣一份文檔呢？
此外，TDD還可以促成良好的代碼設計。因爲你先寫測試代碼，你會盡量的讓代碼調用起來更加簡單方便，這也就促使你去考慮如何更好的設計代碼。以免會出現一個函數裏實現的功能過多，或者和其餘代碼過於耦合而沒法測試的狀況。
固然測試驅動開發除了好處之外，還有神仙打架中紅方表明DHH所提出的一些問題。總結來看，關於TDD的爭議能夠大體從這幾個方面來看，軟件開發應該由什麼來驅動，測試的速度和覆蓋程度，以及設計思想層面等幾方面。從 辯證統一的角度來看，事物有兩個方面， TDD不必定能適用於全部的場景，一樣TDD的侷限性在某些場景下也不見得是對的，若是想要能更好的適用於自身，不只要拿捏好度的問題還要以敏捷的思想來應對問題，好比不該該盲目的制定100%或0%的測試覆蓋率，也不該該固化開發步驟而不顧實際狀況。
因此，在最後的神仙打架中，Kent Beck也表達了David的論述可能會讓TDD浴火重生、鳳凰涅槃的觀點，但願能夠找到更加好的方法。但不管如何， 在咱們實際工做中，不該該由於某些 觀點成爲咱們接受或者拒絕它的理由。正所謂大道甚夷，而民好徑，做爲敏捷開發中的一項優秀實踐來看，TDD只有在真正使用事後才能評價是否已死的問題。那麼你在踐行敏捷開發的時候，是否使用過TDD這種實踐呢，又或是踐行過其餘一些敏捷開發的實踐呢，有沒有評測過你所在的項目中的敏捷開發的成熟度是如何的呢？
沒有那就對了！
華爲雲的DevCloud專業服務正是爲此而生！
針對不一樣的崗位提供了評估的能力，讓開發者能夠對號入座，並基於你所在的崗位、技術獲得客觀、全面、系統的測評以及名師般的學習引導。快來訪問 專業服務平臺，經過我的能力評估，看看本身是什麼水平吧！
本文分享自華爲雲社區《快來看神仙打架啊》，原文做者：敏捷的小智。