.NET單元測試藝術

《.net單元測試藝術》
第i部分 入 門
第1章 單元測試的基本知識 
1.1 單元測試——傳統(tǒng)定義 
1.1.1 編寫“優(yōu)秀單元測試”的重要性 
1.1.2 我們都寫過單元測試(或多或少) 
1.2 優(yōu)秀單元測試的特性 
1.3 集成測試 
1.4 優(yōu)秀的單元測試——定義 
1.5 一個簡單的單元測試實例 
1.6 測試驅動開發(fā) 
1.7 小結 
第2章 第一個單元測試 
2.1 單元測試框架 
2.1.1 單元測試框架的優(yōu)勢提供了什么 
2.1.2 xunit測試框架 
2.2 logan項目的介紹 
2.3 使用nunit的第一步 
2.3.1 安裝nunit 
2.3.2 加載解決方案 
.2.3.3 在代碼中使用nunit特性 
2.4 編寫第一個測試 
2.4.1 assert類 
2.4.2 用nunit運行我們的第一個測試 
2.4.3 修正代碼讓測試通過 
2.4.4 從紅色到綠色 
2.5 更多nunit特性 
2.5.1 setup和teardown 
2.5.2 驗證預期的異常 
2.5.3 忽略測試 
2.5.4 設置測試類別 
2.6 針對狀態(tài)的間接測試 
2.7 小結 
第ii部分 核 心 技 術
第3章 使用樁對象解除依賴 
3.1 樁對象 
3.2 發(fā)現(xiàn)logan對文件系統(tǒng)的依賴 
3.3 確認簡化loganalyzer測試的方法 
3.4 重構設計增強了可測性 
3.4.1 抽取接口，以允許替換底層實現(xiàn) 
3.4.2 在被測類中注入樁對象 
3.4.3 在構造函數(shù)級別上接收一個接口(構造函數(shù)注入) 
3.4.4 接收一個接口作為屬性的get或set的類型 
3.4.5 在調用方法之前獲取一個樁對象 
3.5 重構技術的變種 
3.6 解決封裝問題 
3.6.1 使用internal和[internalvisibleto] 
3.6.2 利用[conditional]屬性標簽 
3.6.3 使用#if和#endif的條件編譯 
3.7 小結 
第4章 用模擬對象做交互測試 
4.1 基于狀態(tài)的測試和交互測試 
4.2 模擬對象和樁對象之間的區(qū)別 
4.3 簡單的手寫模擬對象例子 
4.4 同時使用模擬對象和樁對象 
4.5 一個測試一個模擬對象 
4.6 樁鏈：產生模擬對象或其他樁的一批樁對象 
4.7 手寫模擬對象和樁對象的問題 
4.8 小結 
第5章 隔離(模擬對象)框架 
5.1 為什么使用隔離框架 
5.2 動態(tài)創(chuàng)建偽對象 
5.2.1 在測試中引入rhino mocks 
5.2.2 使用動態(tài)模擬對象替換手寫模擬對象 
5.3 嚴格模擬對象與非嚴格模擬對象 
5.3.1 嚴格模擬對象 
5.3.2 非嚴格模擬對象 
5.4 從偽對象返回值 
5.5 用隔離框架創(chuàng)建智能樁對象 
5.5.1 在rhino mocks框架中創(chuàng)建樁對象 
5.5.2 結合使用動態(tài)樁對象和模擬對象 
5.6 模擬對象和樁對象的參數(shù)約束 
5.6.1 用字符串約束檢查參數(shù) 
5.6.2 使用約束檢驗參數(shù)對象的屬性 
5.6.3 執(zhí)行回調檢驗參數(shù) 
5.7 測試與事件相關的活動 
5.7.1 測試一個事件已被訂閱 
5.7.2 在模擬對象和樁對象中觸發(fā)事件 
5.7.3 測試一個事件是否被觸發(fā) 
5.8 隔離框架中的設置-操作-斷言語法 
5.9 .net中現(xiàn)有的隔離框架 
5.9.1 nunit.mocks 
5.9.2 nmock 
5.9.3 nmock2 
5.9.4 typemock isolator 
5.9.5 rhino mocks 
5.9.6 moq框架 
5.10 隔離框架的優(yōu)勢 
5.11 避免使用隔離框架時的陷阱 
5.11.1 測試代碼缺乏可讀性 
5.11.2 對錯誤的事情做驗證 
5.11.3 一個測試包含多個模擬對象 
5.11.4 測試的細節(jié)太多 
5.12 小結 
第iii部分 測試的代碼
第6章 測試層次及組織 
6.1 讓自動化構建運行自動化測試 
6.1.1 自動構建剖析 
6.1.2 觸發(fā)構建和持續(xù)集成 
6.1.3 自動化構建類型 
6.2 根據(jù)速度和類型組織測試 
6.2.1 分離單元測試與集成測試的人為因素 
6.2.2 綠色安全區(qū)域 
6.3 確保測試在代碼庫中 
6.4 在測試類和被測代碼之間建立映射 
6.4.1 映射測試到項目 
6.4.2 映射測試到類 
6.4.3 映射測試到方法 
6.5 為應用程序打造測試api 
6.5.1 使用測試類的繼承模式 
6.5.2 新建測試工具類和方法 
6.5.3 讓程序員知道你的api 
6.6 小結 
第7章 優(yōu)秀單元測試的支柱 
7.1 編寫可信賴的測試 
7.1.1 決定何時刪除或更改測試 
7.1.2 避免測試的邏輯 
7.1.3 只測試一件事情 
7.1.4 讓測試容易運行 
7.1.5 確保測試覆蓋率 
7.2 編寫可維護的測試 
7.2.1 測試私有的或者受保護的方法 
7.2.2 去除重復代碼 
7.2.3 讓setup方法可維護 
7.2.4 實施測試隔離 
7.2.5 避免多個斷言 
7.2.6 避免測試同一個對象的多個方面 
7.2.7 避免在測試里過度關注細節(jié) 
7.3 編寫可讀的測試 
7.3.1 為單元測試命名 
7.3.2 為變量命名 
7.3.3 讓斷言有意義 
7.3.4 將斷言和動作分離 
7.3.5 setup和teardown 
7.4 小結 
第iv部分 設計與流程
第8章 在組織中引入單元測試 
8.1 怎樣成為變革推動者 
8.1.1 備戰(zhàn)棘手問題 
8.1.2 說服內部人士：擁護者與阻礙者 
8.1.3 洞察切入機會 
8.2 成功之路 
8.2.1 游擊策略(自下而上) 
8.2.2 說服管理層(自上而下) 
8.2.3 從外面找一個專家 
8.2.4 讓過程可見 
8.2.5 鎖定目標 
8.2.6 意識到即將面對的阻礙 
8.3 失敗之路 
8.3.1 缺乏驅動力 
8.3.2 缺乏政治上的支持 
8.3.3 不好的實施和第一印象 
8.3.4 缺乏團隊支持 
8.4 棘手的問題及其答案 
8.4.1 在現(xiàn)有的流程上會增加多少時間 
8.4.2 測試人員的工作會因此受到威脅嗎 
8.4.3 怎么知道這確實可行呢 
8.4.4 有什么可以證明單元測試的好處 
8.4.5 為什么測試部門還是能找到缺陷 
8.4.6 我們有很多沒有測試的代碼：該從哪里開始呢 
8.4.7 使用多種語言開發(fā)：單元測試適用嗎 
8.4.8 如果是軟硬件結合的開發(fā)，該怎么辦 
8.4.9 怎么知道測試本身是否有缺陷 
8.4.10 我的調試器顯示代碼可以正常工作：為什么還需要測試 
8.4.11 必須用tdd的方式來編碼嗎 
8.5 小結 
第9章 修改遺留代碼 
9.1 從哪里開始添加測試？ 
9.2 確定抉擇策略 
9.2.1 容易優(yōu)先策略的優(yōu)缺點 
9.2.2 困難優(yōu)先策略的優(yōu)缺點 
9.3 在重構前寫集成測試 
9.4 重要的遺留代碼單元測試工具 
9.4.1 使用typemock isolator輕松隔離依賴項 
9.4.2 使用depender找出可測性問題 
9.4.3 在java遺留代碼里使用jmockit 
9.4.4 重構java代碼時使用vise 
9.4.5 使用fitnesse在重構前做驗收測試 
9.4.6 閱讀michael feathers的關于遺留代碼的書 
9.4.7 使用ndepend來審查生產代碼 
9.4.8 使用resharper瀏覽和重構生產代碼 
9.4.9 使用simian來檢測重復代碼(和缺陷) 
9.4.10 使用typemock racer來檢測線程問題 
9.5 小結 
附錄a 設計與可測試性 
附錄b 工具和框架