Kent Beck 談單元測試和持續部署

2010年7月2日，Roy Osherove 和 Kent Beck 在 blog.typemock.com 進行了一次對話，話題涉及單元測試（Unit Testing），JUnit Max（Kent 開發的一個單元測試的 Eclipse Plugin，不免費），和面向初創企業的精益方法（Lean Startups）。

單元測試和 JUnit Max
作為軟件開發方法學的大師、極限編程XP的創始人、敏捷宣言的創始人之一，Kent Beck 一直在努力最大化地利用單元測試的價值，他說一些程序員仍然認為單元測試并不是他們的工作，但是單元測試確實能夠提高軟件的質量。目前他正在開發 JUnit Max，這是一個 Eclipse plugin，每當程序員保存一個 Java 源文件的時候，JUnit Max 就會運行測試并報告反饋信息。測試中的錯誤將會如同編譯錯誤一樣被報告給程序員。JUnit Max 的核心思想是測試錯誤應該和編譯錯誤一樣被 IDE 報告給程序員，程序員不需要額外的菜單選項或者運行其他的工具來運行測試。特別是那些經常失敗的測試，對于程序員來說是非常有價值的反饋信息。在測試驅動開發（Test Driven Development – TDD）中，我們重復著這樣一個循環：“編寫一個‘失敗’的測試（Failing Test）” – “編碼實現功能以便讓測試通過”，隨著開發的深入，測試越來越豐富，測試能夠反饋給程序員的信息也越來越多，它們可以幫助程序員找出那些需要改進的代碼。JUnit Max 能夠縮短這個循環的周期，因為它更為頻繁地運行測試和提供反饋。Roy 問道：“當你一個人編碼的時候，你是否嚴格地遵循 TDD，即一定要先寫測試，然后寫實現代碼。我個人發現這并不是一件容易做到的事情，特別是當一個人編碼的時候。” Kent 回答：“視情況而定，有時候并不需要死板地遵循 TDD，比如當我在做一些探索性或者說實驗性的編碼時，并不需要寫測試，因為我只是想嘗試一下某些功能和特性。”

Roy： “你在測試驅動開發中見過的最糟糕的錯誤有哪些？”
Kent：“很多程序員僅僅是拷貝和粘貼測試代碼，但并不理解它們。所以我們經常能看到沒有斷言的測試，同時測試很多邏輯和功能的測試，過于臃腫或者過于短小的測試等等。當然這些錯誤在學習過程中很普遍，也是我們學習的一部分。”

Roy：“你下一步最想嘗試的新概念是什么？”
Kent：“我最近談論的一個主題是 Software G Forces，是關于軟件產品的部署頻率（Frequency of Deployment），這里的部署是指面向最終用戶的部署或者說發布，是生產環境而非測試環境。從前的軟件產品每年（或數年）發布一個新的版本，而現在的軟件產品發布頻率越來越快，從每季度，每月，每周，每天，直至每小時。Kent 提及有一些非常復雜的軟件產品的發布頻率甚至是每天 40 到 50 次。此時 Roy 提出了一個非常好的問題：“產品發布得如此頻繁，我們如何能夠在這么短的時間間隔內獲得用戶反饋呢？”，Kent 回答道：“持續部署（Continuous Deployment）確實需要一些基礎設施建設來支持，比如：自動版本回滾，自動錯誤檢測，系統同時運行多個版本的能力，比如一個服務器集群中不同的服務器上可以運行產品的不同版本。”

Roy 問道：“當你在開發一個產品的時候，你在為客戶創造價值，而持續部署創造的則是一種內在的價值，并且實施過程也是非常復雜的，你怎樣投入時間去實施它呢？是否需要從產品設計的一開始就考慮這些問題呢？”，Kent 答道：“5 年之內市場上可能會有許多持續部署的產品出現，目前我們可能需要自己來尋求解決方案，因為現在它還是一個較新的領域。持續部署的重點之一是及時捕獲系統錯誤，不僅僅是技術層面上的錯誤，同時也包括業務層面。以 Amazon.com 為例，他們評價系統運行的良好程度是以業務運營狀況為依據的，如果銷售額出現不明原因的下降，系統也會發出錯誤警告。”

注：為了不讓文章過長，下半部分的面向初創企業的精益方法（Lean Startups）將在后面發布。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈