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