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

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

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

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

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

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

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

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

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

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

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

問：就Web開發(fā)而言，Python Web和ASP.NET Web有什么區(qū)別？它們各有哪些優(yōu)缺點(diǎn)？

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

問：你認(rèn)為Flask怎么樣？你在Django和Flask之間如何抉擇？

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

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

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

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

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

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

我在《Python Web開發(fā)》的前言中談到了我在第一個項目中的經(jīng)歷。

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

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

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

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

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

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

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

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

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

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

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