你就是不寫 Unit Test 才會沒時間
Author:
Bruce
Date:
2023-02-13
本標題致敬『你就是不寫測試才會沒時間』。
寫
Unit test 可以幫助及早發現程式問題。
假定在系統中已經有存在既有的
Unit test :當一份修改過的程式碼上傳時,在其中的
bug 經過 0.5s 的 Unit test 執行檢查被發現,撰寫此段程式碼的 R&D 花 15 分鐘 (0.25 hours) 修改正確,
bug 週期結束。
|
|
有 Unit test |
|
耗時 |
0.25
hours |
假定在系統中沒有存在
Unit test :當一份修改過的程式碼上傳時,在其中的
bug 經過 2 hours 的 Build 階段, 1 hour QA 建立環境後發現和回報問題,撰寫此段程式碼的 R&D 也花 1 hour 重現和理解問題,再花
15 分鐘 (0.25 hours) 修改正確,再經過一次 2 hours 的 Build 階段, 1 hour QA 建立環境後發現和驗證問題正常,
bug 週期結束。
|
|
沒有 Unit test |
|
耗時 |
7.25
hours |
效率已經差了 29 倍。
用比較寬鬆的時間重算一次:
bug 經過 0.5s 的 Unit test 執行檢查被發現,撰寫此段程式碼的 R&D 花 1 hour 修改正確, bug 週期結束。
|
|
有 Unit test |
|
耗時 |
1
hour |
假定在系統中沒有存在
Unit test :當一份修改過的程式碼上傳時,在其中的
bug 經過 1 hour 的 Build 階段, 0.5 hours QA 建立環境後發現和回報問題,撰寫此段程式碼的 R&D 也花 0.5 hours 溝通和理解問題,再花
1 hour 修改正確,再經過一次
1 hour 的
Build 階段, 0.5 hours QA 建立環境後發現和驗證問題正常,
bug 週期結束。
即使忽視 Build 所花費的時間:
|
|
沒有 Unit test |
|
耗時 |
2.5
hours |
效率還是差了 2.5 倍。
想想看 200 條 Bug 就最少省了公司 300 個工作小時以上 (第一種算法會差 1400 個小時) ,你說是不是該寫
Unit Test ?
留言
張貼留言