摘要：目前就職于，他在各種演講研討會和開發者大會上積極推廣測試驅動開發。問很多敏捷教練都表示訓練新人做測試驅動開發是一件辛苦而進度緩慢的事，并且收益也不是很大。首先是開發的對話式風格。第一個問題就是測試套件的速度。

Harry J.W. Percival目前就職于PythonAnywhere，他在各種演講、研討會和開發者大會上積極推廣測試驅動開發（TDD）。他在利物浦大學獲得計算機科學碩士學位，在劍橋大學獲得哲學碩士學位。Harry Percival著有《Python Web開發：測試驅動方法》一書，該書手把手教你從頭開始開發一個真正的Web應用，并且展示使用Python完成測試驅動開發（TDD）的優勢。你將學到如何在開發應用的每一個部分之前先編寫和運行測試，然后再編寫最少量的代碼讓測試通過——也就是應用TDD理念，寫出簡潔可用、賞心悅目的代碼。

問：很多敏捷教練都表示訓練新人做測試驅動開發（TDD）是一件辛苦而進度緩慢的事，并且收益也不是很大。你在《Python Web開發》中采用了哪些方法來避免這種情況？

這是一個很難的問題！教授TDD這樣的方法是無法保證收效的，但是既然市面上有那么多關于TDD的書和教程，也就證明了人們一旦理解了這種方法，他們的編程方式就會發生改變，而新的方式會令他們感到更加欣喜，所以他們就有了分享的欲望。

讓我的書區別于其他書的地方我認為主要有兩點。首先是《Python Web開發》的“對話式”風格。與其花氣力寫一本學術性、講座式的書，我在寫作本書時，想象的是讀者坐在我身邊和我一起完成一個項目的情景。我就是這樣學習TDD的：和專家結對編程。所以，我沒有選擇發表一系列課程或規則，而是通過真實的例子來演示如何使用TDD來解決問題，同時我還會告訴讀者我腦子里想的是什么，我是如何做決定的，為什么我會使用某種測試方法。

第二點不同在于，我選用了非常實際的例子——真正的項目，用來構建具有真正功能的真正網站。雖然簡單，但是很真實。不像很多教程那樣，比如讓你搭建一個“羅馬數字翻譯器”或其他抽象例子，雖然這樣的示例乍一看讓人覺得清楚明了，但是你很難把這樣的東西應用到真實世界中。

問：從你的角度上說，學習TDD最有效的方法是什么？TDD的學習曲線是否陡峭？

可以這樣說，TDD的理論很簡單，但是實踐很難。只要通過一個簡單的例子就能輕松理解TDD的基本思想，你在任何線上教程中都能找到。但是把這種方法應用到真實世界的項目中可就難了。只有時間的磨礪才能讓你在判斷測試的好壞時找到感覺，什么是有用的，什么是沒有成效的。遺憾的是，獲得這種知識的唯一方法就是時間和經驗，但是我會盡力幫助讀者在正確的路上跑起來。

在這《Python Web開發》中，我努力讓學習曲線盡可能地柔和——我每次只介紹一個概念，并且讓前幾章的內容短小而令人愉快，我堅持每章一個概念為的是讓讀者理解基本概念，哪怕我們開頭學到的只是經過簡化的不切實際的技巧。到了后來我們會開始學習“真正”的方法，這些技巧會稍微復雜一些。相比于提供一步到位的完美解決方案，我認為這種學習方法更好。在書的最后，讀者將會接觸到我和我的同事們每天都在使用的最為真材實料的TDD技巧。

問：你為什么選擇Python作為講解TDD的編程語言？Python是否具有某些其他語言無法比擬的獨特優勢？

我傾向于把Python作為教學語言是因為Python非常簡單——它“不礙事”。Python代碼非常易讀，而且沒有很多礙事的樣板；沒有你在Java中會看到的“public static void main %#￥%%￥”關鍵字。這些東西可能對于大型企業級應用是有效的（沒有定論！），但是在教授編程方法的過程中卻是不折不扣的絆腳石。的確，Python簡單，利于教學，但是Python也很靈活，這也讓很多TDD技巧變得簡單了（比如模擬和修補，我在書中將會講到）。

問：就Web開發而言，Python Web和ASP.NET Web有什么區別？它們各有哪些優缺點？

我必須承認，我對ASP.NET一無所知，所以我也沒什么資格回答這個問題。我知道很多業務之所以使用了ASP.NET是因為它是某種常見的微軟棧的一部分，但是我也知道很多硅谷創業公司都借助Python獲得了巨大的成功（比如Youtube, Instagram, Reddit，等等）。

問：你認為Flask怎么樣？你在Django和Flask之間如何抉擇？

Flask很簡單，但是Django有更多內置功能（或者我們有時會說“自帶電池（功能齊備）”）。我把Flask用在了小型“微服務”應用上，但是對于大應用來說Django是一個很不錯的選擇，因為Django擁有很多強大的特性，比如認證、管理界面，以及各種第三方插件和應用。但是就像任何“一體適用”解決方案一樣，有時效果很好，有時內置Django功能卻并不是你真正想要的。所以要有所權衡，但是到最后，這個決策也沒有那么重要。無論你用哪種工具都可以獲得成功！

問：業務越復雜測試越多，有時甚至比開發時間還長，這樣的情況對于小型創業公司來說肯定是不愿意看到的。關于如何平衡測試和開發，你有什么建議？

我想先退一步來論證這個問題。但是首先必須要說明，我認為復雜的項目并不一定意味著“成比例”的測試時間。但是為了討論需要，我們先假定一段帶有測試的代碼需要兩倍于沒有測試的代碼的時間（雖然有些人會告訴你，如果你很牛的話，寫帶有測試的代碼會比沒有測試的還快）。但是我們還是假定寫測試會多花一倍的時間。如果為一個小型的簡單項目寫代碼需要花費兩倍的時間，那么為復雜的大型項目寫代碼也要花兩倍的時間——比例不會變。

區別在于測試帶來的好處。在一個簡單的項目中，測試并不是特別有價值的。如果你的項目很簡單，你可以輕松快速的完成手動測試。如果你想對代碼進行大改動的話，比如升級核心模塊或者重構中心算法，那么你不需要測試就能完成，只要花很少的時間你就能檢查完畢，并且自信一切沒有問題。

但是對大項目來說，就是另一碼事了。想象一下你參與過的最大的項目，并且想象一下升級一個核心組件的情況——該框架絕對會出現在所有代碼中，而你想為這個組件升級一個帶有新API和新特性的新版本。沒有測試，這將是一個幾乎無法完成的任務。在最近的工作中，我們升級了我們的Django核心版本，多虧有測試，我們只花了幾星期時間就完成了。到了最后，我們得以確保一切都能順利運行，而且當我們把項目部署到客戶端時，我們也有信心客戶不會看到回歸。但是如果沒有測試的話，我們就無法完成。可以毫不夸張地說，如果沒有測試我們連試都不會試，因為風險太大了。而且我們就得一直將就著用老版本Django，沒準這個版本最終會老到不被支持的程度，并且還會產生各種各樣的安全問題……

所以隨著時間推移，到頭來還是復雜的項目會收獲TDD真正的好處。沒有測試，你將不敢在你的系統上做太大的改動。你會回避重構，因為風險太大。技術債越積越多，做出新改動會越來越難，而項目上的工程師則會越來越悶悶不樂。

我在《Python Web開發》的前言中談到了我在第一個項目中的經歷。

在實踐測試的過程中，這是最難的部分之一——這是一種投資，需要花費額外的時間和努力，雖然可以即刻提升代碼，但是“真正”的好處卻是在未來才能兌現的。所以只有團隊和管理層具有前瞻性思維才能完成。雖然速度對于創業公司來說至關重要，但是如果公司因為欠下太多技術債而無法繼續創新和響應市場需求的話，創業最終會走向失敗。

問：在測試驅動開發中，每一個類，每一個方法都需要寫測試用例嗎？如何在不花費太多時間的情況下做到面面俱到？

我在書中的第4章談到了這個問題。你需要找到自己的平衡點。你可以為自己辯護，如果一個功能規模很小而且無關緊要，可能就不需要測試了。但是危險在于：隨著時間推移會發生什么？可能這個簡單的功能會變得稍稍大一點，加了一個if語句。但是這個功能沒有測試，而增加新測試就需要額外的努力，所以加入沒有測試的新代碼可能也沒有關系。然后這個功能增加了一個for循環，一點一滴，變得越來越復雜，也越來越需要測試，但是由于每個階段的心理屏障，這個功能可能永遠都沒有測試。所以也許最安全的做法就是在最開頭的時候做測試，因為在已經有了測試的情況下增加新測試就會容易很多。畢竟，如果功能真的很簡單的話，寫第一個測試應該也難不到哪去吧？

問：我們知道測試驅動開發在小項目中是非常有效的，但是TDD是否適用于中型甚至大型項目？在大型項目中使用TDD時是否有哪些需要注意的事情？

正如我所說的，TDD的真正好處只有在項目達到一定規模和年限時才會顯現出來。但是沒錯，確實有一些問題需要注意。第一個問題就是測試套件的速度。這件事很容易就會被做過頭，而且有些人執著于測試速度，但是這個問題還是很有必要注意一下的。如果你有測試分散在低級“單元”測試和高級“功能”測試中，那么你應該擔心的問題是：你的單元測試的運行時間何時會變成幾分鐘，或者功能測試何時會變成幾小時。測試方法的核心就是在合理的情況下盡可能快地得到反饋。有時你會發現，你的測試時間不再隨著應用的大小成比例增加，而是隨著復雜度增加出現幾何級增長。但是這個問題是可以解決的。我在《Python Web開發》后面的章節中談到了如何取得平衡，特別是最后一章（第22章）。

問：遺留代碼通常對于測試來說不太友好，如果要把TDD應用在遺留代碼上，你有哪些建議？

我不能說自己是這方面的專家，但是關于這個問題Michael Feathers寫了一本很不錯的書，叫做《修改代碼的藝術》。總體的建議是：不要絕望。在大量的已有代碼庫上增加測試可能看起來像個不可能的任務，但是這件事是可以完成的，只要隨著時間循序漸進就好。一旦你決定開始增加測試，那么你就可以選擇在每次向代碼中加入新需求時增加測試，或者在每次出現需要修理的bug時增加測試。隨著時間推移，測試覆蓋量將會增加，而你得以開始重構應用，使其測試性更強，并且加速這個過程。

問：前端的測試驅動開發是否可以擴展到后端？軟件工程中是否有哪些模型值得推薦？

在書中，我談到了使用不同的測試層來測試前端（呈現在真實瀏覽器中的HTML渲染和Javascript性能）和后端（連接數據庫并且處理數據的控制器和視圖）。通過使用“高級”層的“真正”測試，我稱其為功能測試，通過Selenium我們可以測試前端和整體應用。低級“單元”測試被用于測試前端Javascript和后端Python代碼的多帶帶組件。在《Python Web開發》的第18章和第19章中，我談到了這方面的問題，這種模型名為“雙循環TDD”和“外向內TDD”。

另外，我需要聲明這本書并不只是關于TDD的。這本書講的是一種用結構化、嚴格而且漸進的方式來做軟件工程的完整方法。在我剛開始編程時，我只是在“碼磚”——靠自己找答案，用“牛仔style”編程，為了讓程序運行，我經常走捷徑。最開始這樣做沒什么問題，但是隨后你就會陷入麻煩。

在接下來的幾年中我逐漸學會利用工具和技巧、以結構化的方法來編程，這就是我想在這本書中傳達的。我說的是TDD，沒錯，但是也包括很多其他東西：使用Git這樣的版本管理工具并且完成無數微小的漸進式的提交。雖然聽起來像是毫不相關的主題，但事實上這是和測試驅動的工作方式緊密相關的，這種方式的核心就是微小而漸進的改變。我演示的一些“DevOps”思想講的并不僅僅是構建和測試你自己的機器，同時也關于如何搭建登臺環境，以及如何配合自動部署腳本使用測試來確保代碼在生產環境下、服務器上、互聯網上，以及本地計算機上順利運行。我也講到了如何集成第三方系統，以及使用持續集成服務器在一夜之間運行構建，我還談到了一點關于在敏捷開發方法（如XP）中使用TDD的方法……我努力想要把我知道的所有“碼磚”和“真正的軟件開發”之間的區別，通過一本書傳達出來。

更多精彩，加入圖靈訪談微信！