# Clean Code Ch. 9 單元測試
- TDD
- 第一法則：在撰寫一個單元測試（測試失敗的單元測試）前，不可撰寫任何產品程式。
- 第二法則：只撰寫剛好無法通過的單元測試，不能編譯也算無法通過。
- 第三法則：只撰寫剛好能通過當前測試失敗的產品程式。
- 如果這樣寫程式，會寫出上百上千條測試，產生管理上的問題

- 讓測試程式整潔
- 醜陋的測試 > 沒有測試 ? Wrong
- 醜陋的測試 = 沒有測試
- 髒到不敢改 or 懶得修改測試導致拖延開發
- 測試程式跟產品程式一樣重要
- 測試程式不是次等公民
- 測試的好處
- Code with more confidence
- 髒的測試程式會限製 修改程式碼的能力
- 測試程式越醜 -> 程式碼會變得更醜
- 測試讓修改程式變得可行
- 整潔的測試
- 可讀性，可讀性，可讀性
- Clarity, Simplicity, Density of expression(言簡意賅)
- 建立特定領域的測試語言
- 建立特定的專用函式方便測試
- 雙重標準
- 產品程式的執行環境 != 測試程式的執行環境
- 產品(記憶體限制)；測試邏輯(資源無限制)
- 整潔好寫 > 執行效率
- 一個測試一次斷言 (Assert)
- 就像 Rubocup 規定一個 'it' 只能有一個 expect :3
- 優點: 好理解。 缺點: 重複程式碼
- Rspec 中用 `before` or shared_context 解決重複程式碼
- 不用嚴格遵守，但斷言數量應該盡量減少
- 一個測試一個概念
- 一個概念裡最小化斷言的數量
- 一個測試函式只測試一個概念
- F.I.R.S.T 原則
- Fast 夠快，測試執行夠快才會想執行，有執行才會發現問題
- Independent
- 測試程式不應相互依賴
- Repeatable
- 測試程式可在任何環境重複執行
- Self-Validation
- 測試程式應該輸出 boolean
- 好像是廢話
- Timely
- 單元測試要在完成產品程式**之前不久**撰寫
- 補充
- catch http request: https://github.com/vcr/vcr
- loader that make tests faster: https://github.com/rails/spring
- Rails Test book: https://pragprog.com/titles/nrtest3/rails-5-test-prescriptions/