--- tags: extract --- # [Working Effectively with Legacy Code](https://www.tenlong.com.tw/products/9789864344000) # CH04 接縫 對既有程式碼撰寫測試很不容易 ## 4.1 清單 - 程式是… 一長串清單 → 模組 (物件導向) - 重複使用的頻率 (我：故設法轉化為更廣泛的問題) ## 4.2 接縫 # CH05 工具 IDE 和 toolchain 以外的工具 ## 5.1 重構 - 留意工具是否正確保留行為 (工具應要檢查) * 以能夠在無測試保護下使用 * 否則視為手動重構 - 未能保留行為的例子 ## 5.2 [mock object](http://www.mockobjects.com/) 解依賴後，測試所需的填補物。 ## 5.3 單元測試 - 藉 使用者介面 測試的工具 不太好 * 介面容易變化 * 距離受測功能較遠 * 不易查明原因 * 貴 - xUnit * 以程式語言寫測試 * 測試互不干擾 * 可分組執行 ### 5.3.1 JUnit - 用法 * 繼承 `TestCase` 類別 * 撰寫 `void testXXX()` * 使用 `assertEquals()` 等函式檢查 - 原理 * Java 能以 反射機制 找出 測試函式 * 對每個測試函式都建立各自的物件實體 → 故測試之間能互不影響 - `setUp()`/`tearDown()` * 建構共同的初始環境；進行共同的後續處理。 * 何不 ctor/dtor？ 進行測試時才呼叫，避免資源浪費。 ### 5.3.2 CppUnitLite - CppUnit 欲仿照 JUnit，卻沒有方式能搜尋測試函式。 * 須在 `suite()` 手動註冊 - CppUnitLite 以 `TEST()` 巨集解決註冊問題 * 也減少使用 C++ 特性 ### 5.3.3 NUnit - .NET (C#/VB/…) - 與 JUnit 相似 - 特色是使用 attribute ### 5.3.4 其他 www.xprogramming.com ## 5.4 整合測試 整合測試 (多個類別) 用 整合測試工具 ### 5.4.1 [Fit](http://fit.c2.com/) - 維護 HTML 表格 * 描述 輸入/輸出 * 定義一些表格處理的程式碼 (?? - 促進 案主 與 開發人員 溝通 * 案主 寫測試 * 開發人員 設法令測試通過 ### 5.4.2 [FitNesse](http://fitnesse.org/) - Wiki 版的 Fit # CH06 - 額外的工作 (解依賴/寫測試) 是否划算？ * 事先 撰寫測試 也許能減少隨後 除錯 的時間與挫折 * 即便無助當前開發，也有助未來回顧、理解。 - 強迫團隊一定要寫測試的實驗 * 熬過撞牆期 - 在時限壓力下，難免想先硬幹出來，再補測試與重構。 * CH16 對程式碼理解不足 * CH24 感到絕望時 - 先嘗試在單元測試裡建立出類別的實體 * CH09 類別無法放入測試 * CH10 成員函式無法於測試執行 * 實在不行再參考本章做法 ## 6.1 新函式 - 例子：消除重複項目 * 直接在舊函式裡實作，對舊行為影響大，且不可測試。 * 最小化舊函式的改動，以新函式撰寫功能，至少新函式可測 (可藉 TDD 開發)。 - 測試新函式 * 傳 null 技術 (?? * 公用靜態函式 (數量多了可再併成類別) - pros/cons * 新舊清楚區隔 (我：有乾淨的程式產出，而非更多的垃圾) * 放棄測試舊函式與舊類別 ## 6.2 新類別 - 例子：增加標題列 * 最小化舊函式的改動，以新類別撰寫功能，至少新類別可測 (可藉 TDD 開發)。 * 也許會讓物件抽象概念更混亂，但盡量納入既有概念。 + 本例：抽出共同介面 (皆是生成器) + 也可能成為別的概念，與其他模組的相似邏輯共用。 - 其他例子 * 報稅軟體的日期檢查成為新類別 * 如果連新函式都無法 - pros/cons * 無需修改標頭檔 * 物件抽象概念複雜化 ## 6.3 包函式 ## 6.4 包類別