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

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

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

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

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

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

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

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

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

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

我傾向于把Python作為教學(xué)語言是因?yàn)镻ython非常簡單——它“不礙事”。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一無所知，所以我也沒什么資格回答這個(gè)問題。我知道很多業(yè)務(wù)之所以使用了ASP.NET是因?yàn)樗悄撤N常見的微軟棧的一部分，但是我也知道很多硅谷創(chuàng)業(yè)公司都借助Python獲得了巨大的成功（比如Youtube, Instagram, Reddit，等等）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

問：前端的測試驅(qū)動(dòng)開發(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)的方式來做軟件工程的完整方法。在我剛開始編程時(shí)，我只是在“碼磚”——靠自己找答案，用“牛仔style”編程，為了讓程序運(yùn)行，我經(jīng)常走捷徑。最開始這樣做沒什么問題，但是隨后你就會陷入麻煩。

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

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