如何用Code Coverage來衡量單元測試的成果
- 在build的時候要自動去跑測試（使用CI，CD當作工具）> 大於0%
- 關心相對趨勢 大於 絕對數字，衡量相對的數字，評估code coverage的數值有沒有比昨天高，每一次針對PROD的程式碼修改都要加上測試，這樣這個數值只會往上不會往下。鼓勵持續的COMMIT > 持續整合，每天都要COMMIT個5~6次或7~8次。
- 那些測試的投資報酬率高：為什麼要寫測試？目標是要提升產品品質。假設這段PROD CODE沒有BUG，其實不需要為它寫測試。那什麼東西的投資報酬率最高？
- 1. 要修正的BUG（BUG越晚發現修正成本就更高）
- 2. 實務上常跑到的scenario
- 3. 最主要的情境
- 4.和錢有關的
- 5.和人命有關的（EX：自動駕駛系統）
- 6. 最常改到的CODE，可以避免被改錯
- 那code coverage的意義如下：
- 觀察沒有被含蓋到的情境：判斷要不要補測試
- Dead Code：根本就不會跑到的Code（代表這一段PROD CODE不會跑到）
最好導入的方式
從上面看來，兩個最好導入的方式：1. 針對所有BUG的修改去寫測試，2. 針對新的專案去寫測試
然後要確認code coverage不可以往下掉。
假如現在有一陀爛CODE，要增加新功能在那堆爛CODE裡，先把爛CODE抽成method，然後再抽成新的Class
針對爛CODE的public的情境先寫測試，會讓需要寫測試的範圍變小很多。
測試的品質
- 測試的程式一定要重構
- 測試的語意一定要清楚明白，一般Assert都會抽出成一個func，這是為了讓測試更容易理解，可以很簡單的的從測試的程式碼由語意就能理解這個測試要做什麼
- 寫測試的難度會反應程式的好壞
