不管你是對單元測試或是測試驅動開發的新手，還是已經有豐富經驗的人，都能在這本書裡找到適合自己的內容。——《無瑕的程式碼》作者 Robert C. Martin（Bob大叔）《單元測試的藝術》很重要，在好幾年前就應該要有這麼一本書了！——Michael Feathers這本書將單元測試所有相關知識解釋地完整透徹。——連任八屆微軟最有價值專家 陳仕傑(91)理解如何撰寫單元測試，以及讓它們變得可維護、可讀、可被信任，是這本書的主要內容，不管你使用的是何種程式語言跟編輯器。這本書涵蓋了撰寫單元測試的基本知識，並且講解互動測試的基礎，介紹了在真實世界撰寫、管理和維護單元測試的最佳實踐。目錄致謝第二版　序第一版　序譯者序前言關於本書關於封面圖片PART I　入門Chapter 1　單元測試基礎1.1　逐步定義單元測試1.1.1　撰寫優秀單元測試的重要性1.1.2　我們都寫過（某種）單元測試1.2　優秀單元測試的特質1.3　整合測試1.3.1　與自動化單元測試相比，非自動化整合測試的缺點1.4　什麼是優秀的單元測試1.5　一個簡單的單元測試範例1.6　測試驅動開發1.7　成功進行TDD 的三種核心技能1.8　小結Chapter 2　第一個單元測試2.1　單元測試框架2.1.1　單元測試框架提供哪些東西2.1.2　xUnit 框架2.2　LogAn 專案介紹2.3　NUnit 的第一個步驟2.3.1　安裝NUnit2.3.2　載入方案的方式2.3.3　在程式中使用NUnit 的特性2.4　撰寫第一個測試程式2.4.1　Assert 類別2.4.2　用NUnit 執行第一個測試2.4.3　增加正向的測試2.4.4　由紅到綠：測試成功2.4.5　測試程式風格2.5　使用參數來重構測試2.6　更多的NUnit 特性2.6.1　setup 和teardown2.6.2　驗證預期的例外2.6.3　忽略此測試2.6.4　NUnit 的流利語法2.6.5　設定測試分類2.7　測試系統狀態的改變，而非驗證回傳值2.8　小結PART II　核心技術Chapter 3　透過虛設常式解決依賴問題3.1　虛設常式簡介3.2　找到LogAn 中對檔案系統的依賴3.3　如何讓測試LogAnalyzer 更簡單3.4　重構設計以提昇程式碼的可測試性3.4.1　擷取介面以便替換底層實作內容3.4.2　依賴注入：在被測試單元中注入一個假的實作內容3.4.3　從建構函式注入一個假物件（建構函式注入）3.4.4　用假物件來模擬異常3.4.5　透過屬性get 或set 注入假物件3.4.6　在呼叫方法之前才注入假物件3.5　重構技術的變形3.5.1　透過擷取與覆寫直接模擬假結果3.6　克服封裝的問題3.6.1　使用internal 和[InternalsVisibleTo]3.6.2　使用[Conditional] 特性3.6.3　使用 #if 和 #endif 進行條件編譯3.7　小結Chapter 4　使用模擬物件驗證互動4.1　基於值、狀態與互動的測試4.2　模擬物件和虛設常式物件的差異4.3　手刻模擬物件的簡單範例4.4　同時使用模擬物件和虛設常式物件4.5　每個測試只用一個模擬物件4.6　假物件鏈：用虛設常式物件來產生模擬物件或其他虛設常式物件4.7　手刻模擬物件和虛設常式物件的問題4.8　小結Chapter 5　隔離（模擬）框架5.1　為什麼要使用隔離框架5.2　動態產生假物件5.2.1　在測試中使用NSubstitute5.2.2　用動態假物件來取代手刻假物件5.3　模擬回傳值5.3.1　同時使用模擬物件和虛設常式物件5.3.1.1　驗證物件是帶著某些屬性的情況5.4　測試事件相關的活動5.4.1　測試事件監聽者5.4.2　測試事件是否觸發5.5　現有的.NET 隔離框架5.6　隔離框架的優缺點5.6.1　使用隔離框架時應避免的陷阱5.6.2　測試程式可讀性變差5.6.3　驗證了錯誤的東西5.6.4　一個測試中有多個模擬物件5.6.5　過度指定的測試5.7　小結Chapter 6　深入了解隔離框架6.1　受限框架和不受限框架6.1.1　受限框架6.1.2　不受限框架6.1.3　基於探查器的不受限框架是如何運作的6.1.4　框架揭露了不同的探查器能力6.2　好的隔離框架的價值6.3　支援適應未來和可用性的功能6.3.1　遞迴假物件6.3.2　預設忽略參數6.3.3　大範圍偽造6.3.4　假物件的非嚴格行為6.3.5　非嚴格模擬物件6.4　隔離框架設計反模式6.4.1　概念混淆6.4.2　錄製與重播6.4.3　黏性行為6.4.4　語法過於複雜6.5　小結PART III　測試程式碼Chapter 7　測試階層和組織7.1　執行自動化測試的自動化建置7.1.1　建置腳本結構7.1.2　觸發建置和整合7.2　依據速度和種類對應的測試分類7.2.1　分開整合測試和單元測試的人為因素7.2.2　綠色安全區域7.3　確保測試程式是版本庫管理的一部分7.4　將測試類別的位置與被測試程式相對應7.4.1　將測試對應到專案7.4.2　把測試對應到類別7.4.3　將測試對應到明確的工作單元入口7.5　注入橫切面關注點7.6　為應用程式建立測試API7.6.1　使用繼承類別繼承模式7.6.2　建立測試輔助類別和方法7.6.3　把你的API 介紹給開發人員7.7　小結Chapter 8　好的單元測試的支柱8.1　撰寫可信任的測試8.1.1　決定何時刪除或修改測試8.1.2　避免測試中帶著邏輯8.1.3　每次只測試一個關注點8.1.4　把單元測試和整合測試分開8.1.5　用程式碼審查確保程式碼覆蓋率8.2　撰寫可維護的測試8.2.1　測試私有或保護的方法8.2.2　去除重複的程式碼8.2.3　具可維護性的設計來使用Setup 方法8.2.4　實作測試隔離8.2.5　避免對不同的關注點進行多次驗證8.2.6　物件比較8.2.7　避免過度指定8.3　撰寫可讀性高的測試8.3.1　單元測試的命名8.3.2　變數命名8.3.3　有意義的驗證8.3.4　驗證和操作分離8.3.5　setup 和teardown8.4　小結PART IV　設計與流程Chapter 9　在組織中導入單元測試9.1　逐步成為導入變革的領頭羊9.1.1　準備好面對各種質疑9.1.2　說服組織內成員：支持者和反對者9.1.3　找到可能的切入點9.2　成功之道9.2.1　游擊式的進行（從下而上）9.2.2　說服高層（從上而下）9.2.3　引入外援9.2.4　讓進度可見9.2.5　設定具體目標9.2.6　應對阻礙9.3　失敗原因9.3.1　缺乏驅動力9.3.2　缺乏政策支援9.3.3　糟糕的實現和第一印象9.3.4　缺少團隊支持9.4　影響因素9.5　質疑和回答9.5.1　現有流程加入單元測試需增加多少時間9.5.2　單元測試是否會搶了QA 飯碗9.5.3　證明單元測試確實有效的方式9.5.4　單元測試有用的證據9.5.5　QA 部門還是能夠找到bug 的原因9.5.6　我們有大量未經測試的程式碼，應該從哪裡開始9.5.7　我們使用了多種程式語言：單元測試是否可行9.5.8　軟硬體結合的開發9.5.9　確保測試中沒有bug 的方式9.5.10　偵錯器已經證明我的程式沒問題，但還需要測試的原因9.5.11　測試驅動開發的必要性9.6　小結Chapter 10　遺留程式碼10.1　從哪裡開始加入測試10.2　決定選擇策略10.2.1　先易後難策略的優缺點10.2.2　先難後易策略的優缺點10.3　在重構前撰寫整合測試10.4　針對遺留程式碼進行單元測試的重要工具10.4.1　使用不受限的隔離框架來輕鬆隔離依賴項10.4.2　使用JMockit 測試Java 遺留程式碼10.4.3　重構Java 程式碼時使用Vise10.4.4　重構前使用驗收測試10.4.5　閱讀Michael Feathers 關於遺留程式碼的書10.4.6　使用NDepend 來分析產品程式碼10.4.7　使用ReSharper 瀏覽和重構產品程式碼10.4.8　 使用Simian 和TeamCity 發現重複的程式碼（和bug）10.5　小結Chapter 11　設計與可測試性11.1　為什麼在設計的時候要關心可測試性11.2　可測試性的設計目標11.2.1　預設情況下將方法設定為虛擬方法11.2.2　使用介面導向的設計11.2.3　預設情況下將類別設計成可繼承的11.2.4　避免在包含邏輯的方法裡面初始化具體類別11.2.5　避免直接呼叫靜態方法11.2.6　避免在建構式和靜態建構式中包含邏輯程式碼11.2.7　把單例邏輯和單例持有者分開11.3　可測試性設計的利弊11.3.1　工作量11.3.2　複雜度11.3.3　洩漏敏感的智慧財產權11.3.4　有時無法進行11.4　可測試性設計的替代方案11.4.1　設計爭論與動態型別語言11.5　難以測試設計的範例11.6　小結11.7　更多資源Appendix A　工具和框架A.1　隔離框架A.1.1　MoqA.1.2　Rhino MocksA.1.3　Typemock IsolatorA.1.4　JustMockA.1.5　Microsoft Fakes（Moles）A.1.6　NSubstituteA.1.7　FakeItEasyA.1.8　FoqA.1.9　Isolator++A.2　測試框架A.2.1　Mighty Moose（又叫：ContinousTests）持續執行器A.2.2　NCrunch 持續執行器A.2.3　Typemock Isolator 測試執行器A.2.4　CodeRush 測試執行器A.2.5　ReSharper 測試執行器A.2.6　TestDriven.NET 執行器A.2.7　NUnit GUI 測試執行器A.2.8　MSTest 執行器A.2.9　PexA.3　測試APIA.3.1　MSTest API：微軟的單元測試框架A.3.2　MSTest for Metro Apps（Windows Store）A.3.3　NUnit APIA.3.4　xUnit.netA.3.5　FluentAssertion 驗證APIA.3.6　Shouldly 輔助APIA.3.7　SharpTestsEx 輔助APIA.3.8　AutoFixture 輔助APIA.4　控制反轉容器A.4.1　AutofacA.4.2　NinjectA.4.3　Castle WindsorA.4.4　Microsoft UnityA.4.5　StructureMapA.4.6　微軟的託管可擴充框架（MEF）A.5　資料庫測試A.5.1　為資料庫進行整合測試A.5.2　使用TransactionScope 還原（rollback）資料修改A.6　Web 測試A.6.1　vonnaA.6.2　Team System web testA.6.3　WatirA.6.4　Selenium WebDriverA.6.5　CoypuA.6.6　CapybaraA.6.7　JavaScript 測試A.7　UI 測試（桌面）A.8　執行緒相關的測試A.8.1　Microsoft CHESSA.8.2　Osherove.ThreadTesterA.9　驗收測試A.9.1　FitNesseA.9.2　SpecFlowA.9.3　CucumberA.9.4　TickSpecA.10　BDD 風格的API 框架

作者 Roy Osherove從事程式設計已超過15年，他在世界各地擔任顧問及訓練團隊，教導有關單元測試的藝術以及測試驅動開發（TDD）。部落格網址為ArtOfUnitTesting.com。譯者 陳仕傑(91)連任八屆微軟最有價值專家（2010~2017）著作：《ASP.NET MVC 5：網站開發美學》（12刷）、《ASP.NET MVC4 網站開發美學》譯作：《敏捷開發實踐》審校：《進入IT產業必讀的200個.NET面試決勝題》講師：各大技術研討會、知名企業內訓與公開培訓講師、知名部落客