要知道的事
- 這是單元測試的藝術的閱讀筆記
- 筆記的意思就是不一定會有心得
- 這篇主要是導讀
譯者序
- TDD , Test First to Think First
- 什麼是好的單元測試？
- 單元測試三支柱:可信任 可讀性 可維護
- 綠色安全區域
- 實務上導入的指引
入門建議
- 了解如何隔離相依(Part II)
- Stub 與 Mock 的差異,熟練隔離框架(NSubstitute)
- 如何撰寫優秀的單元測試(Part III)
進階建議
- 如何撰寫優秀的單元測試(Part III)
- 如何在組織中導入單元測試(Part IV)
- 針對遺留代碼的重構與測試,以及可測試性設計(Part IV)
避免
- 測試不穩定
- 過度指定
- 一次不只測一件事
- 測試程式重複過多
- 可讀性差
關於本書
前言
有寫測試, 也不保証專案成功,
一個失敗的單元測試案例,
作者歸納原因如下,
- 脆弱的測試(Prod 改一點,測試就錯一大片)
- 不易維護
- 測試間相護依賴
- 可讀性差
作者推薦的框架
學習路線圖
- Part I 基礎知識
- Part II 測試框架
- Part III 最佳實踐
- Part IV 組識導入/遺留代碼/設計
目錄
- 入門
- 什麼是優秀的單元測試
- 單元測試與整合測試的分別
- 第一個單元測試
- 核心技術
- Stub
- IoC(DI)
- 值、狀態與互動
- 測試框架
- 事件
- 深入了解測試框架
- 測試程式碼
- 自動化
- 綠色安全區域
- 可信任/可維護/可讀性
- 設計與流程
- 組織導入
- 遺留代碼
- 設計與可測試性
定義單元測試
什麼是優秀的單元測試
- 自動化, 可重複執行
- 容易實現*
- 到第二天還有存在的意義(非臨時性的,ex:hotfix)
- 任何都可以一鍵執行
- 執行速度快
- 結果一致
- 可以完全控制(不與外部相依)
- 獨立於其他測試
- 失敗時,錯誤應該是明確的
整合測試
- 整合測試相依於真實物件
- 整合測試的結果不穩定
- 整合測試與單元測試應該被分開(見 ch7.2.2)
- 整合測試執行時間長
- 依據現實狀況無法完全控制
- 缺點: 一次測試的東西太多
理解測試趨動開發
- TDD 不保證產品會成功
- 步驟
- 寫一個失敗的測試
- 寫一個符合測試預期的產品程式碼,以通過測試
- 重構
TDD 的核心技能
- 可維護、可讀、可靠(這本書的目的)
- 寫出可維護、可讀、可靠的測試不等於 TDD,至於如何寫優秀的 TDD,作者推薦閱讀〈Test-Driven Development:by Example〉
- 就算執行 TDD,也不保証能設計一個完善的系統,作者推薦閱讀Growing Object-Oriented Software, Guided by Tests與無瑕的程式碼
簡單說就是:
- 寫好測試
- 測試先行(TDD)
- 設計
作者認為這是三種技能, 同時學習三種技能門檻會相當的高, 最後導致放棄.
小結
- 優秀的測試就是
- 自動化
- 容易撰寫
- 執行快速
- 任何人都可以執行,並得到相同結果
揪錯
本書資源
(fin)