單元測試的藝術(第二版) 讀書筆記
為The Art of Unit Testing With Examples in C# 的中譯版本，譯者為業界知名的講師91
書籍介紹
本書前半部分講述如何開始撰寫單元測試、單元測試的技巧、介紹隔離框架與用法，後半部分著重於如何撰寫好的單元測試、以及在組織或團隊中要導入開發測試程式，會遇到的困難與解決方法。
一個優秀的單元測試所具備的特質
- 自動化
- 容易撰寫
- 執行快速
- 重複執行得到一樣的結果
單元測試的命名慣例
- 專案：[專案名稱].UnitTests
- 類別：[被測試類別名稱]Tests
- 測試案例：[工作單元(方法名稱或是抽象的描述)][情境][預期結果]
單元測試框架-NUnit
單元測試的核心技術
- 虛設常式(Stub)：產生一個可控物件，代替一個外部的相依物件，不會對虛設常式進行驗證
- 模擬物件(Mock)：驗證被測試物件是否如預期般呼叫這個假物件，會對模擬物件進行驗證
在單元測試中，可以使用自己實作虛設常式與模擬物件，但自己實作這些類別比較花費時間，在一般的情況下，可以使用模擬框架來實作。
隔離模擬框架-NSubstitute
測試階層與組織
- 測試自動化，使用自動化建置流程，頻繁的執行測式
- 將整合測試與單元測試分開，建立綠色安全區域，確保區域內的測試都可以通過
好的單元測試的支柱
可信賴
- 決定何時刪除或修改測試
- 避免測試中帶有邏輯：避免出現邏輯判斷(if、switch)與迴圈(foreach、for、while)
- 每次只測試一個關注點
- 把單元測試與整合測試分開
- 用程式碼審查確保程式碼覆蓋率
可維護性
- 只測試公開的方法
- 去除重複的程式碼
- 實作測式隔離
- 避免對不同的關注點進行多次驗證
可讀性
- 命名單元測試與變數
- 有意義的驗證
- 驗證與操作分離
在組織中導入單元測試
找到可能的切入點
- 選擇小團隊
- 建立子團隊
- 考慮專案的可行性
- 使用程式碼與和測試審查作為工具
成功之道
- 游擊式的進行(由下而上)：由開發者採納這樣的變革，管理者也願意支持
- 說服高層(由上而下)：藉由管理職權直接進行變革
- 引入外援：透過外部顧問來進行變革
- 讓進度可見
- 設定具體目標：提高測試程式覆蓋率，同時也要進行程式和測試審查、減少重複出現的bug、降低修復bug的時間
- 應對阻礙
失敗原因
- 缺乏驅動力
- 缺乏政策支援
- 糟糕的實現和第一印象
- 缺少團隊支持
結語
這不單單是一本講述單元測試實作與技術面的書，同時也提到技術決策面與管理面的問題。我自己的經驗是，在時程很緊迫的情況下，通常被犧牲的一定都是測試，有些管理階層會說這些測試交由QA人員測試即可，但我認為，如果開發程式沒有用單元測試來驗證自己的功能是不是正確，那根本不算是真正的完成。有單元測試的保護，在進行程式需求變更或重構時也比較有信心不會改壞，也會讓新的人員加入團隊時，只要看一下單元測試就可以了解目前的程式提供了什麼功能，加快了解程式的速度。