XML 之父 Tim Bray 在日前發(fā)表的一篇博文中，基于自身的多年軟件開發(fā)經(jīng)驗(yàn)，分享了關(guān)于軟件測試的那些事。“我非常確信，在我有生之年，對(duì)軟件發(fā)展的最大貢獻(xiàn)不是來自面向?qū)ο蠓椒ê透呒?jí)語言、函數(shù)式編程、強(qiáng)類型、MVC 或其他任何東西，而是來自測試文化的興起。”
成熟的軟件開發(fā)人員非常清楚測試的重要性。但是從我的經(jīng)驗(yàn)來看，很多人在這方面做得還不夠。所以我寫下這篇文章的目的是要警醒行業(yè)，或許這對(duì)于我們的從業(yè)人員來說本是多此一舉，但現(xiàn)實(shí)顯然不是這樣。
本文的靈感來自于 的兩個(gè) 帖子，這里引據(jù)其中的幾句話：“你聽到的幾乎所有關(guān)于軟件測試的建議都是糟糕的。這些建議要么看上去就很糟糕，要么會(huì)導(dǎo)致糟糕的結(jié)果，要么會(huì)讓你專注于錯(cuò)誤的事情（通常是工具），結(jié)果分散了注意力”，“幾乎沒有團(tuán)隊(duì)會(huì)編寫富有表現(xiàn)力的測試、建立清晰的界限、快速可靠地運(yùn)行，并且只會(huì)因有用的原因失敗。大家的重點(diǎn)都錯(cuò)了。”（注意： 顯然身處測試行業(yè)。）
帖子都彎彎繞繞、很難摸清脈絡(luò)，所以我從中貼兩張截圖出來。
我先亮明我的觀點(diǎn)：我認(rèn)為這些不規(guī)則的所謂的“結(jié)構(gòu)圖”是大錯(cuò)特錯(cuò)軟件測試的來源，而且影響嚴(yán)重。
背景
自 1979 年以來，我一直從事軟件開發(fā)工作。雖然我的觀點(diǎn)很可能是錯(cuò)的，但這并不是因?yàn)槲胰狈?jīng)驗(yàn)。我做過的幾乎所有有意義的工作都是底層基礎(chǔ)設(shè)施的東西：解析器、消息路由器、數(shù)據(jù)可視化框架、網(wǎng)絡(luò)爬蟲、全文搜索。所以如果你不在基礎(chǔ)設(shè)施領(lǐng)域，我的一些發(fā)現(xiàn)可能就不那么有說服力了。
在我編程生涯的前 20 年，比如說直到 2000 年軟件測試的來源，行業(yè)內(nèi)幾乎沒有軟件測試的位置。一個(gè)后果是，如同 經(jīng)常被引用的一句話：“如果建筑師按照程序員編寫程序的方式建造建筑物，那么飛來的第一只啄木鳥就會(huì)摧毀整個(gè)文明。”
那時(shí)，對(duì)于自己寫的任何軟件，我總會(huì)在幾年后開始討厭它，因?yàn)樗兊迷絹碓酱嗳鹾涂膳隆，F(xiàn)在回頭想想，我抗拒的大概是那些未經(jīng)測試的代碼給人帶來的體驗(yàn)，因?yàn)榻?jīng)常會(huì)有一些小更改由于難以理解的原因意外而引發(fā)“大災(zāi)難”。
2000 至 2010 年的某個(gè)時(shí)候，情況開始發(fā)生變化。我的看法是，最初的推動(dòng)力或多或少來自 Ruby 社區(qū)，并隨著 Rails 的興起而加速。我開始聽到“測試的感染”（test-）這個(gè)詞，我注意到如果提交的代碼沒有像樣的單元測試，它們很容易被無情拒絕。
其他人告訴我，他們最初被圍繞 的《重構(gòu)》一書中的討論打動(dòng)，這本書最早出版于 1999 年，告訴大家你無法真正重構(gòu)未經(jīng)測試的代碼。
特別是我記得自己在 2010 年參加了蘇格蘭 Ruby 技術(shù)大會(huì)，會(huì)上似乎有一半的演講是關(guān)于測試最佳實(shí)踐和技術(shù)的。我在那里學(xué)到了很多我今天仍在應(yīng)用的知識(shí)。
我非常確信，在我有生之年，對(duì)軟件發(fā)展的最大貢獻(xiàn)不是來自面向?qū)ο蠓椒ê透呒?jí)語言、函數(shù)式編程、強(qiáng)類型、MVC 或其他任何東西 ，而是來自測試文化的興起。
我的信念
我們現(xiàn)在做事的方式好得多了。用回前面建筑師和程序員的比喻來說，文明不用再害怕啄木鳥了。
例如：我在谷歌和 AWS 工作的那些年里，我們遇到過很多中斷和故障，但很少是因?yàn)槟硞€(gè)軟件錯(cuò)誤這樣簡單的原因造成的。拙劣的部署、造成障礙的錯(cuò)誤配置、證書問題（真是讓人頭疼）、DNS 小問題、實(shí)習(xí)生使用 腳本做負(fù)載測試、金絲雀故障……痛苦的記憶來自很多因素，但往往不會(huì)僅因?yàn)橐粋€(gè)小錯(cuò)誤。
我不記得我是什么時(shí)候被“感染”的，但我可以保證，一旦你被感染，你永遠(yuǎn)不會(huì)容忍未經(jīng)測試的代碼了。
是的，你可以在上過公共廁所后不洗手；是的，你可以用手指吃意大利面，但負(fù)責(zé)任的成年人不會(huì)做這些事情，他們也不會(huì)交付未經(jīng)測試的代碼。順便說一句，我后來也不再討厭我開發(fā)了一段時(shí)間的軟件了。
隨著時(shí)間的流逝，我對(duì)糟糕測試的容忍度越來越低。我阻止別人升職、給別人打低分、斥責(zé)高級(jí)開發(fā)經(jīng)理，而且一般都沒得商量。我可以不樹敵，可以容忍（大多數(shù)）情況，因?yàn)槲易鹬厮恕⒋擞焉坪透挥型樾摹５谶@個(gè)問題上我不會(huì)后退。
所以，我至死都會(huì)堅(jiān)持這項(xiàng)原則（呃，我想應(yīng)該是一系列原則）：
單元測試是對(duì)軟件未來的一項(xiàng)必不可少的投資。測試覆蓋率數(shù)據(jù)很有用，你應(yīng)該密切關(guān)注它。未經(jīng)測試的老舊代碼庫可以而且應(yīng)該逐步改進(jìn)單元測試需要使用單組 IDE 組合鍵非常快速地運(yùn)行，并且完全可以像打寒戰(zhàn)一樣每隔幾秒鐘運(yùn)行一次。測試教毫無意義；只做有用的事情。單元測試賦予代碼審查者權(quán)力。集成測試非常重要且非常困難，尤其是在微服務(wù)環(huán)境中。集成測試需要 100% 通過，有失敗被忽略是不行的。集成測試需要運(yùn)行得“足夠快”。加入基準(zhǔn)測試對(duì)測試很有好處。
現(xiàn)在我將擴(kuò)展上述列表中的聲明。其中一些不需要進(jìn)一步的拓展（例如“單元測試應(yīng)該運(yùn)行得很快”）。
但首先… 你能證明測試的有效性嗎？
哦，不能。我四處尋找有關(guān)測試效果的高質(zhì)量研究，但沒有找到什么結(jié)果。這并不令人驚訝。因?yàn)槟阈枰业絻蓚€(gè)強(qiáng)大的團(tuán)隊(duì)來執(zhí)行重要的開發(fā)任務(wù)，并且在規(guī)模、結(jié)構(gòu)、工具、技能水平和工作實(shí)踐——在除測試之外的所有方面的表現(xiàn)都大致相同。然后，還需要在十年或更長的周期內(nèi)研究他們的生產(chǎn)力和質(zhì)量差異。據(jù)我所知，從來沒有人這樣做過，對(duì)這一結(jié)論我是很有信心。所以我們只剩下了經(jīng)驗(yàn)積累，Nero Wolfe 稱之為“經(jīng)驗(yàn)總結(jié)出來的智慧”。
單元測試，現(xiàn)在和以后都很重要
當(dāng)你創(chuàng)建一個(gè)新特性并實(shí)現(xiàn)一系列函數(shù)來完成它時(shí)，不要自欺欺人地認(rèn)為你足夠聰明，提前知道哪些東西容易出錯(cuò)，哪些將成為瓶頸，哪些將是你的繼任者難以理解的。畢竟沒有人足夠聰明！因此，只要不是單行代碼的內(nèi)容都要編寫測試。
上面那張 的圖中“實(shí)現(xiàn)細(xì)節(jié)”的標(biāo)簽是反對(duì)單元測試的，這讓我很不爽。我在這里嗅到了不接地氣的架構(gòu)師的味道，這些人認(rèn)為所有的工作就是在白板上正確地放置方框和箭頭，而不是親手去寫分號(hào)和 if 語句。如果你的基礎(chǔ)微服務(wù)代碼沒有經(jīng)過充分測試，那么你就是在聚沙成塔而已。
在經(jīng)過良好單元測試的代碼庫中工作會(huì)給開發(fā)人員帶來勇氣。如果重新實(shí)現(xiàn)一兩個(gè) API 會(huì)帶來一些小的改變，那么你可以大膽一點(diǎn)去做。因?yàn)橛辛肆己玫膯卧獪y試，即使你搞砸了，你也會(huì)很快就發(fā)現(xiàn)問題。
請(qǐng)記住，代碼的讀取和更新頻率高于編寫頻率。我個(gè)人認(rèn)為，好的測試在第一次開發(fā)過程中就可以幫上開發(fā)人員的忙，并且不會(huì)減慢他們的速度。就我對(duì)這一職業(yè)的了解，單元測試為將要學(xué)習(xí)和修改這些代碼的后續(xù)開發(fā)人員們，帶來了顯著的生產(chǎn)力提升并減輕了他們的痛苦。這就是業(yè)務(wù)價(jià)值所在！
那我們是否可以在哪里放寬單元測試覆蓋率呢？比如早在 2012 年，我就寫過關(guān)于測試 UI 代碼的文章，尤其是關(guān)于移動(dòng) UI 代碼。給它們編寫測試太難了，在某些情況下可能不是一項(xiàng)好的投資。
另一個(gè)例子是 Java 世界專屬的，存在依賴注入框架的情況下，你會(huì)得到非常大的文件，其中包含數(shù)以千計(jì)的配置亂碼[*cough**cough*]，生命有限，實(shí)在沒時(shí)間研究它們。
還有一些非常罕見的異常處理場景，你的數(shù)據(jù)中心很可能在遇到它們之前就陷入了困境，此時(shí) 會(huì)是你手頭的那堆麻煩里最不起眼的，所以，也許我們不應(yīng)該沉迷于那些 if err != nil 子句。
覆蓋率數(shù)據(jù)
我并不會(huì)強(qiáng)求代碼庫應(yīng)該達(dá)到某個(gè)覆蓋率。但是這些數(shù)據(jù)其實(shí)很有用，你應(yīng)該注意下它。
首先，找到特殊情況——覆蓋率明顯過低（或高）的文件，然后查找簽入之間的更改。
覆蓋率數(shù)據(jù)不僅僅是一個(gè)百分比數(shù)字。當(dāng)我基本完成某段代碼時(shí)，我喜歡運(yùn)行一個(gè)測試，開啟覆蓋，然后快速瀏覽所有重要的代碼塊，查看綠色和紅色的側(cè)欄。每次這樣做我都會(huì)得到驚喜：往往在有些文件上我本以為我的單元測試很聰明，但覆蓋率實(shí)際上差了很多。這不僅讓我想要改進(jìn)測試，它還教會(huì)了我一些我原不知道的關(guān)于我的代碼如何對(duì)輸入做出反應(yīng)的知識(shí)。
話雖如此，我非常尊重一些軟件團(tuán)隊(duì)，他們有嚴(yán)格的覆蓋率要求并能堅(jiān)持下去。AWS 有一個(gè)團(tuán)隊(duì)，在他們的 CI/CD 管道中實(shí)際上有一個(gè) 100% 覆蓋率的 檢查。我不確定這是否合理，但這些人正在基礎(chǔ)設(shè)施的關(guān)鍵部分編寫非常底層的代碼，在這種情況下不合理的東西可能也是合理的。而且他們比我聰明。
另外，我經(jīng)歷過的所有團(tuán)隊(duì)工作，都會(huì)遇到一些測試不足、拖累工作的遺留代碼。即使是像我這樣的測試狂也不會(huì)要求別人將高覆蓋率單元測試改裝到那些破東西上。
我見過一項(xiàng)很成功的策略，它有兩個(gè)部分：首先，當(dāng)你對(duì)沒有單元測試的函數(shù)進(jìn)行任何重大更改時(shí)，請(qǐng)編寫單元測試。其次，導(dǎo)致覆蓋率下降的簽入是不允許的。
這很有效，因?yàn)楫?dāng)你在應(yīng)對(duì)大型老舊代碼庫時(shí)，更新通常不會(huì)均勻地分散在其中，代碼庫中會(huì)有一些有用行為聚集的熱點(diǎn)。所以如果你應(yīng)用這個(gè)策略，代碼“熱區(qū)”的測試覆蓋率會(huì)有機(jī)增長，達(dá)到相當(dāng)不錯(cuò)的水平，而其他代碼可能多年沒有人接觸或查看過，它們被忽略掉也沒關(guān)系。
“不要宗教”
測試應(yīng)該是最務(wù)實(shí)的活動(dòng)，沒有意識(shí)形態(tài)介入的余地。
請(qǐng)不要跟我扯什么 mock、stub、fake，沒人在乎。在一個(gè)相關(guān)主題上，當(dāng)我發(fā)現(xiàn)很多人在針對(duì) 運(yùn)行代碼的單元測試中使用 Local 時(shí)，我感到非常驚訝。但它真的很有效，速度很快，而且比編寫另一個(gè) mock 或設(shè)置一個(gè)到實(shí)際云服務(wù)的鏈接要省事很多。不要教條主義！
然后來談 TDD/BDD 信仰。有時(shí)，對(duì)于某些人來說，它很有用，給他們帶來了更多力量。但對(duì)我來說它的純粹形式從來沒什么用，因?yàn)槲业木幋a風(fēng)格在早期階段往往是混亂的，我一直在不斷地重構(gòu)和重構(gòu)函數(shù)。如果我在開始編寫它們之前就知道我想讓它們做什么，那么 TDD 可能是有意義的。另一方面，當(dāng)我已經(jīng)草擬了一組我認(rèn)為合理的方法，并且正在為基本代碼編寫測試時(shí)，我會(huì)提前準(zhǔn)備并為還沒寫出來的代碼編寫更多測試。我這個(gè)樣子沒法成為 TDD“教會(huì)成員”，但我不在乎。
還有另一種信仰：在 Java 中對(duì)私有方法進(jìn)行單元測試并不容易，Java 錯(cuò)了。有些人聲稱你不應(yīng)該測試這些方法，因?yàn)樗鼈儾皇穷惡霞s的一部分，那些人也錯(cuò)了。為了方便測試，妥協(xié)封裝并讓方法非私有是完全合理的。或者出于同樣的原因應(yīng)該編寫 API 來獲取接口，而非類對(duì)象。
當(dāng)你針對(duì)復(fù)雜的 API 運(yùn)行大量測試時(shí)，很容易就可以編寫一個(gè) () 幫助程序，將正確布置參數(shù)并針對(duì)結(jié)果運(yùn)行標(biāo)準(zhǔn)化檢查。如果你不這樣做，你最終會(huì)得到很多重復(fù)的剪切粘貼代碼。
這里有爭論的余地，沒有教條的空間，我通常對(duì)此不大同意，因?yàn)楫?dāng)我更改了某些東西、并且是我以前從未見過的單元測試失敗時(shí)，我不想在弄清楚發(fā)生了什么之前還得去搞清楚一堆幫助程序。
無論如何，如果你的工程師正在編寫帶有有效測試的代碼，請(qǐng)不要跟他們講任何廢話。
審查人是你的朋友
有一次一個(gè)同事來找我尋求幫助，查看之后發(fā)現(xiàn)他們的問題很棘手。然后我讓他們向我展示代碼庫，我提出了一些審查請(qǐng)求。
我看的前幾段代碼沒有單元測試，但確實(shí)有注釋說“稍后進(jìn)行單元測試”。我走進(jìn)他們的團(tuán)隊(duì)房間說：“伙計(jì)們，我們現(xiàn)在需要談?wù)劇！?/p>
在這里我想強(qiáng)調(diào)的是：單元測試一旦推后，就不會(huì)有人做了！
以及重點(diǎn)是，代碼審查的目的不是正確性檢查。審查人有權(quán)假設(shè)代碼是有效的。審查人應(yīng)該檢查 O(N3) 瓶頸、可讀性問題、笨拙的函數(shù)參數(shù)、不穩(wěn)定的錯(cuò)誤處理等。如果你沒有足夠的測試來證明你的代碼的基本正確性，那么要求審查人考慮這些事情是不公平的。
進(jìn)一步地說，我在審查時(shí)經(jīng)常會(huì)遇到這樣的情況，我很難弄清楚開發(fā)人員到底想在某段代碼中完成什么。但首先，我會(huì)轉(zhuǎn)到單元測試并查看它在做什么，因?yàn)橛袝r(shí)從這里就可以明顯看出開發(fā)人員所設(shè)想的函數(shù)用途。這也適用于需要修改代碼的后續(xù)開發(fā)人員。
集成測試
做出本文前面所展示的圖片的人似乎都認(rèn)為這很重要，當(dāng)然他們是對(duì)的。不過，我不確定“集成”和“端到端”之間的區(qū)別是否那么重要。
問題是我們?cè)趶膯误w遷移到微服務(wù)，于是這些測試變得更加重要，但也讓它們更難構(gòu)建。如果可以，這是堅(jiān)持使用簡單的單體應(yīng)用的另一個(gè)很好的理由。
這反過來意味著你必須確保為你的集成測試規(guī)劃時(shí)間，包括設(shè)計(jì)和維護(hù)時(shí)間。（單元測試只是基本編程預(yù)算的一部分。）
我知道這些測試很難寫，我曾與其他優(yōu)秀的團(tuán)隊(duì)一起工作，但他們的集成測試都很糟糕。
不好的一面是它們需要跑幾個(gè)小時(shí)，這個(gè)就沒什么好說的，因?yàn)闀r(shí)間目標(biāo)經(jīng)常沒法達(dá)成。我們這么說吧：集成測試不需要像單元測試一樣快，但它們確實(shí)需要足夠快，這樣你就可以在去上廁所或喝咖啡，或被聊天窗口打斷時(shí)運(yùn)行它們了。不過這還是很難實(shí)現(xiàn)的目標(biāo)。
最后，我一次又一次地看到集成測試日志顯示很多失敗，一些開發(fā)人員會(huì)說“哦，是的，那些測試是不穩(wěn)定的，它們有時(shí)會(huì)失敗。”出于某種原因，他們認(rèn)為這是可以的。要么測試執(zhí)行了一些可能在生產(chǎn)中失敗的任務(wù)，在這種情況下你應(yīng)該將失敗視為 ，或者這些任務(wù)不會(huì)在生產(chǎn)中復(fù)現(xiàn)，在這種情況下你應(yīng)該將它們從該死的測試套件中取出，然后測試就會(huì)運(yùn)行得更快了。
基準(zhǔn)測試
因?yàn)槲铱偸窃谔幚韺?duì)性能非常敏感的代碼，所以我經(jīng)常會(huì)編寫基準(zhǔn)測試，一段時(shí)間后我養(yǎng)成了將其中一些留在測試套件中的習(xí)慣。因?yàn)槲乙呀?jīng)觀察到很多由性能下降引起的中斷，比如某個(gè)配置改動(dòng)將 TLS 計(jì)算從硬件推入 Java 字節(jié)碼這樣的蠢事。你真的會(huì)希望提前發(fā)現(xiàn)這種情況。
工具鏈
可用的工具有很多，足夠用了。讓你的團(tuán)隊(duì)就他們將要使用的內(nèi)容達(dá)成一致，并成為相應(yīng)的專家，然后不要把你的問題歸咎于工具上。
我們的處境
我認(rèn)為我們的整體情況還不錯(cuò)，因?yàn)榇蠖鄶?shù)理智的組織都開始表現(xiàn)出相當(dāng)好的測試紀(jì)律，尤其是在服務(wù)端代碼方面。就像我說的，我在生產(chǎn)代碼中看到的錯(cuò)誤比以前少了很多。
而且每個(gè)團(tuán)隊(duì)都必須與那些可怕的、未經(jīng)檢驗(yàn)的、停滯不前的遺留代碼池作斗爭。打起精神來吧，處理它們只是工作的一部分。而且不管怎樣，你可能也寫過那樣的代碼。
但每天總有團(tuán)隊(duì)會(huì)迷失方向，“開始在上完廁所后不洗手”。不要這樣做，并且不要發(fā)布未經(jīng)測試的代碼。
關(guān)于作者
Tim Bray，全名 Bray，有“XML 之父”之稱，XML 和 Atom 標(biāo)準(zhǔn)的創(chuàng)建者，曾先后就職于 DEC、Sun、 等公司。