這個主題有一個技藝線其他三篇——設計判準、系統架構、改既有的程式——都沒有的特徵：收錄的書彼此不同意。測試該寫到什麼粒度、協作對象該不該用 mock 替換、測試該綁在行為上還是結構上——這些問題有兩個互相對立的傳統，而多數讀者是在讀到第二本、發現它跟第一本說法相反的時候，才知道自己一直在照著其中一派做而不知道有另一派。

所以這篇的選讀判斷跟那三篇不同：不是「先讀哪本再讀哪本」，是先知道分歧在哪，再決定要站哪邊。

收的書分成兩組。第一組四本各自站在一個位置上：Kent Beck 的《Test-Driven Development: By Example》給出原始定義，Freeman 與 Pryce 的《Growing Object-Oriented Software, Guided by Tests》把其中一派的主張寫到最完整，Khorikov 的《Unit Testing Principles, Practices, and Patterns》是後來對那一派的系統性批評——這三本不同意的是同一個問題的答案，那個問題是「測試的單元是什麼」。Bach 與 Bolton 的《Taking Testing Seriously》站在第四個位置上，它不同意的是問題本身：它主張要先分開的是兩種活動——「執行事先寫好的判準」與「設計判準、發現沒人想到要問的問題」——而不是單元的大小。

第二組一本，Aniche 的《Effective Software Testing》，處理的是立場確定之後仍然要回答的操作問題——這些測試案例是怎麼推出來的。前四本沒有一本給這個程序。

站內對這個分歧的立場與推導在 行為優先的 TDD 方法論，那篇處理的是「所以我們怎麼做」；這裡處理的是「該讀哪本、每本代表什麼位置」。

起點是 Kent Beck 的 Test-Driven Development: By Example

這本是 TDD 的原始定義，2003 年出版，做的事情很單純：從頭到尾走完兩個小專案，把紅燈、綠燈、重構這個循環示範幾十次。讀它的價值不在學到技巧，在於看清楚那個循環的節奏究竟有多小——書中的步伐比多數人想像的細，細到會讓第一次讀的人覺得沒必要。

它是起點的理由是 Freeman 與 Pryce 那本、Khorikov 那本都在跟它對話。分歧從一個定義開始：測試的單元是什麼。Beck 的用法把單元當成一組協同工作的類別，測試對外的行為；後來的另一派——書市慣稱倫敦學派——把單元縮到單一類別，把所有協作者換成 mock。兩派的所有差異都從這個定義分岔出去。

證據來源是單一路徑的個人經驗，形式是作者逐步演練自己的實踐而非論證。時效上，範例是 Java 與 Python 的舊版本，測試框架也隔了兩個世代；紅綠重構的節奏與「讓測試驅動設計」這個主張不依賴那些。

處境相容性上，這套節奏預設提交的粒度由寫的人自己決定。流程若要求每個提交對應一張工單、或測試必須跟功能在同一個 PR 送審，書中那個細到讓人覺得沒必要的步伐就落不了地，要先改流程、或改用較粗的循環。

這本書幾乎不需要前置作業，但它預設讀者寫過測試——完全沒寫過的人會看不出那些步驟在避免什麼；先在自己的專案寫過幾個測試再來讀，那些步驟的用意才看得出來。繁體中文版《Kent Beck 的測試驅動開發：案例導向的逐步解決之道》，博碩出版、陳仕傑譯。

想看 mock 那一派的完整主張時讀 Growing Object-Oriented Software, Guided by Tests

Steve Freeman 與 Nat Pryce 這本是倫敦學派的代表作，也是它最完整的一次陳述。主張是由外而內開發：從最外層的驗收測試開始，往內每遇到一個還不存在的協作對象就先用 mock 頂替，於是 mock 不只是測試工具，而是用來發現物件之間該有什麼關係的設計手段。

這個定位常被誤解。多數人把 mock 當成「真實依賴太慢所以換掉」，而這本書的主張是相反的——mock 是在那個依賴還不知道長什麼樣的時候，用寫測試的方式把它的介面逼出來。書中貫穿全書的那個範例完整走過一次這個流程，是它跟只講技巧的測試書的差別。

它也是這個主題裡爭議最集中的一本。批評集中在同一點：這種寫法讓測試綁在物件的協作結構上，於是重構內部結構時測試會大量壞掉，而重構本來不該破壞測試。這個批評成不成立，取決於單元怎麼定義——那正是 Khorikov 那本要處理的問題。

證據來源是單一路徑的個人經驗（兩位作者十年的系統開發），形式是主張加上一個長篇範例。時效上，範例是 Java 與 JMock，那部分已經很遠；由外而內的流程與 mock 當設計手段這個主張不依賴語言。

讀這本要先有一次自己造成的後果：寫過一套後來覺得難維護的測試。還沒有那個經驗時，這本的主張跟批評它的主張聽起來都有道理，讀的人沒有判斷的依據——它因此適合排在自己的測試開始出現維護負擔之後，而不是照出版順序讀。查不到中譯本（2026 年 8 月查）。

要一組可以拿來評分的判準時讀 Unit Testing Principles, Practices, and Patterns

Vladimir Khorikov 這本（2020）是單元定義這條線上最後出版的一本，也是唯一給出一套可以拿來評測試的通用判準的一本。四支柱是防止回歸、抵抗重構、快速回饋、易於維護，而書中的核心論證是前三者互相衝突、不可能同時最大化，所以測試設計是取捨而非最佳實踐。這套判準有一類測試評不了：為了替沒有測試的程式碼建立行為快照而寫、用完就丟的那種（改既有的程式 收的 Feathers 那本教的手法），它在抵抗重構與易於維護上必然低分，而那正是它該有的樣子。四支柱預設被評的測試要長期留著。

它對倫敦學派的批評就建立在這組判準上：把所有協作者 mock 掉會讓測試耦合到實作結構，因而在「抵抗重構」這一項上得分很低——而那一項是四支柱裡唯一不能用其他項補償的，因為一個會誤報的測試套件最終會被團隊忽略。作者主張的是古典學派：單元是行為而非類別，只有跨越應用邊界的協作對象（資料庫、外部服務）才該替換。

這本的用法跟前兩本不同：它不是拿來讀完的，是拿來當量尺的。手上有一套自己覺得不對勁的測試時，逐項打分數比讀任何主張都快看出問題在哪。

證據來源是單一路徑的個人經驗加上理論建構，形式是原則加判準——這是本篇收錄的書裡唯一嘗試把測試設計寫成可推導體系的。範例是 C#，但判準本身與語言無關。時效上沒有明顯過時的部分——四支柱的取捨與工具世代無關。

這本要有量測的對象：手上一套實際在跑、而且開始造成負擔的測試。沒有那套測試，四支柱之間的取捨不會浮現——它們互相衝突，而衝突要有一套實際的測試當標的才看得見。還沒有這樣一套測試的話，可以先知道這本存在，等負擔出現再拿出來用。查不到繁體中文版，簡體中文版《單元測試：原則、實踐與模式》（2026 年 8 月查）。

想知道機器接手判準之後人還做什麼時讀 Taking Testing Seriously

James Bach 與 Michael Bolton 這本（Wiley，2025 年 11 月）是 Rapid Software Testing 這一派的完整陳述。它跟前三本不在同一個座標系裡：前三本爭的是單元的邊界該畫在哪，這本主張要先分開的是兩種活動——checking（對一個已經被決定的事實做二元評估，判準事先寫下、原則上可以交給機器）與 testing（設計判準本身、發現沒有人想到要問的問題、判斷觀察到的現象算不算問題）。作者的立場是自動化能接手的只有前者，而前者的品質完全取決於當初設計它的那次後者。

這個分界是這一派的起點，理由是自動化的邊界由判準寫不寫得下來決定，與工具能力無關。作者同期公開談論過 AI 與這個分界的關係；書的目次未能取得，這裡不指涉它在書中的位置與篇幅。

證據來源是兩位作者長期的教學與顧問實踐加上一套自建的術語體系，形式是主張與啟發式的目錄而不是逐步演練——它不像 Freeman 與 Pryce 那本有一個貫穿全書的範例可以跟著做。時效上是本篇最新的一本，術語體系本身不依賴任何工具世代。

處境相容性上要先知道一件事：這一派的語彙（checking、oracle、heuristic、探索式測試的活動記錄）與多數團隊日常使用的詞彙不重疊，讀的時候要一邊做術語對照。它也預設讀者有機會親自操作產品——判準要在觀察當下才成形是這套主張的核心，而完全只寫單元測試、不碰成品的人拿不到那個觀察位置。查不到中譯本（2026 年 8 月查）。

要一套推出測試案例的程序時讀 Effective Software Testing

Maurício Aniche 這本（Manning，2022）處理的是前四本都沒有給的一項：這些測試案例是怎麼被推出來的。Khorikov 給的是評分用的量尺，Beck 給的是循環的節奏，這本給的是從需求推導案例的步驟——先從規格切出等價類與邊界，再用覆蓋準則檢查有沒有漏掉分支，接著設計方法與類別的契約（前置條件、後置條件、不變量），最後回頭問這段程式碼的可測試性是不是設計本身的問題。

它跟量尺型的書搭配起來沒有重疊：量尺回答「手上這套測試好不好」，這本回答「還缺哪幾個案例」。手上一套測試被評為分數低而不知道要補什麼時，缺的通常是這本教的推導程序。

證據來源是學術訓練加業界實踐（作者當時同時任教於 Delft 理工大學並在業界帶技術培訓），形式是步驟加練習，每章有可自己動手的題目。範例是 Java 與 JUnit，推導程序本身與語言無關。時效上沒有明顯過時的部分。

前置經驗要求比前四本低——它不預設讀者已經寫過一套難維護的測試，也不預設讀者對兩派分歧有立場。缺點的另一面是它不處理立場問題：讀完之後仍然要自己決定單元畫在哪，那要回到前面四本。作者另有一套與本書同主題的免費線上課（見下方公開課段），內容重疊但形式互補。查不到繁體中文版，另有簡體中文譯本（2026 年 8 月查）。

為什麼只收這幾本

立場那四本彼此不同意，而它們的分歧點正是這個主題最難自己判斷的那一個。讀完會發現自己原本以為的「測試最佳實踐」是某一派的立場，而那個發現比任何單一技巧有用。Aniche 那本收在旁邊，因為立場選定之後「案例怎麼推出來」仍然沒有答案。

測試的書市有兩大類不在這裡。一類是特定框架的操作手冊，那類的時效跟框架版本綁死，且屬於教學系列的範圍。另一類是把測試金字塔或某個覆蓋率目標推銷成普適規則的書——它們的問題是規則脫離了推導它的取捨，而本篇收的書恰好證明那些取捨還在爭論中。

Mark Winteringham 的《Software Testing with Generative AI》（Manning，2024）是 2026 年 8 月這一輪查到唯一整本處理「用生成式工具做測試」的書，本書單評估後不收。內容是工具操作層——用編碼助理引導 TDD、向對話模型取回饋、呼叫 API 生測試資料——落在上一段第一類的排除範圍裡，時效跟工具版本綁死。這個判定只針對本篇的收錄軸（立場分歧），要找那類操作內容的人它是現成的入口。

Roy Osherove 的《單元測試的藝術》繁中版流通度高，本書單未評估它。它的定位偏向操作手冊而非立場陳述，跟本篇要回答的問題（分歧在哪）不同軸；要判斷它現在的價值需要對照第三版的改寫幅度，這裡沒有做。

Gerard Meszaros 的《xUnit Test Patterns》是測試異味與模式的完整目錄，本書單未評估——它的體量與參考書性質接近 Code Complete，而這個主題目前沒有那個生態位的需求。

影音路徑在別的關鍵字底下

以「軟體測試」為關鍵字找到的公開課，2026 年 8 月這一輪查到的集中在怎麼當一個測試工程師——測試種類的名詞、工具操作、面試會問什麼，那類內容預設有標準答案可以教。本篇要交付的是幾本書彼此不同意在哪，是一組還在爭論中的立場，兩者不在同一層。

但這不表示這個主題沒有影音路徑，它出現在別的關鍵字底下。問「分歧在哪」的影音內容出現在 TDD、software engineering、craftsmanship 這幾個關鍵字下，而不在 software testing 下——後者的檢索結果被測試工程師的職涯內容佔滿。讀不動長篇文字的讀者要換的是關鍵字，不是放棄。

供給的形態依製作者的商業模式分成三種，判斷免費內容拿得到多少要先看這個：

形態免費內容的位置這個主題拿得到什麼
內容型（付費課程靠免費內容引流）影音平台頻道，量大且完整Dave Farley 的 Continuous Delivery 與 Modern Software Engineering 頻道、Emily Bache 的頻道（approval testing 與重構的逐步演練）、Khorikov 的 Enterprise Craftsmanship 部落格
顧問型（課程面向企業、不靠影音引流）長篇文字，不是影音Bach 與 Bolton 的 developsense.com 與 satisfice.com；想走影音繞過長文的人在這一派上沒有路徑
平台型（全免費、靠上游產品變現）課程平台本身工具操作為主（Selenium、Cypress、Playwright、Appium），填不了立場分歧那個缺口

學術機構開的免費課是這一輪查到最貼近本篇主題的影音資源：Delft 理工大學在 edX 上的 Automated Software Testing 系列由 Aniche 與 Arie van Deursen 開設，內容是單元測試、覆蓋準則與可測試性設計，與上面收錄的《Effective Software Testing》同源而形式互補。

整條線的供給狀況寫在 工程技藝書單 的公開課段。

本篇的「最新」「唯一」「查不到中譯」這幾類宣稱都是相對於查證時點的。下次新增或替換任何一本書時，整篇重掃一次這三類句子——它們不會自己跟著新書更新。

這個主題接到哪裡

測試寫不出來常常是設計的訊號而非測試技巧的問題——難測的程式碼通常是耦合太緊。那條路徑走 設計判準與日常實踐。既有程式碼沒有測試而必須先補，那是 改既有的程式 裡 Feathers 那本處理的問題。

站內自己的測試分層策略、協議整合驗證與實機教訓看 Testing 測試策略；本站在 mock 學派分歧上採取的立場與推導在 行為優先的 TDD 方法論。

程式碼由 agent 產出、而人不打算逐行讀時，判準該落在哪走 模組六：Agent 產出程式碼的驗證——那裡處理的是本篇四本立場書共同預設而在那個情境下失效的前提：測試由懂需求的人寫，而那個人會讀自己的程式碼。Bach 與 Bolton 那本的 checking 與 testing 分界是這條路線的上游概念。