領導要求單元測試覆蓋率，都996了，沒時間寫怎麼辦？

軟體開發時，要不要寫單元測試，寫多少，投入多少資源達到多高的覆蓋率，這個話題討論由來已久。尤其是處於早期階段的小型創業團隊，在面對時間和資源壓力時，難以平衡和取捨。

回到原點分析，得出結論不難。程式碼一定要測試，大家都同意吧。越早發現bug，越容易修復，成本也越低。所以還是投入產出比的一個考量。

一，為什麼要寫單元測試？

1. 保證程式碼質量，及早發現bug

單元測試由開發工程師來寫，相比測試工程師，更清楚深入的瞭解程式碼邏輯，而且在設計測試用例時，重新審視檢查被測試程式碼，發現問題或者重寫，這樣的經歷對於寫過單元測試的工程師並不陌生。

2. 修改過的bug，避免再次發生

軟體總是有bug的，如何才能做到bug越修越少？修復一個bug，就增加一個對應的單元測試用例，這樣隨著用例庫的豐富，程式碼質量逐漸提高。

3. 改動程式碼時，避免引入新bug

如果已有正確邏輯被測試用例覆蓋，那麼當新改動影響到它時，就能及時發現糾正錯誤。

4. 迴歸測試

增加新功能、修復bug時，測試工程師的關注點都是有針對性的，不可能每次都進行全量回歸測試。這時能做到的，就是透過執行全量單元測試，確保新提交的程式碼沒有影響到已有功能，保障迴歸測試。

二，更多好處，歡迎補充

1. 保證程式碼可測，最佳化設計

程式碼的可測性非常重要，比如上千行的長函式、一長串的if-else，這樣的設計都需要進行最佳化改造。

2. 重構程式碼時，保證原有功能邏輯正確

單元測試可以被理解為期望的功能邏輯，所以在重構程式碼時，新函式要能夠透過已有的測試用例。

3. 持續整合和自動化部署的保障

和自動構建系統整合後，每次有程式碼提交變動時，全量執行單元測試用例庫，確保程式碼質量。

4. 單元測試是最有效的文件

單元測試完整的描述了程式碼功能，並且在程式碼改動時始終保持一致。

三，單元測試好寫嗎？

1，好寫

程式碼要完成什麼功能，把這些期望和要求寫成單元測試，assert斷言。如果程式碼功能都描述不清楚，那麼這些程式碼可能是不需要的，更有可能是有bug的。

2，不好寫

兩方面，一是有些程式碼可測性不高，要修改設計甚至重寫；二是要達到較高的單元測試覆蓋率甚至100%，設計完善的測試用例，工作量很大。測試用例庫是一個長時間積累的過程，隨著開發功能、修復bug，逐漸補充完善。

3，時間投入難保證

在趕進度、壓工期時，時間成本和人力資源的壓力很大：是交付了再說呢？還是堅持寫單元測試？根據實際情況評估bug或者故障帶來的損失吧。

四，怎麼寫？

以Java開發為例，常用的JUnit + Mockit，使用起來非常高效。

1，舉個例子，被測試函式parseMsg()，讀取ActiveMQ訊息內容，轉換成JSONObject

2，測試函式，模擬輸入TestMessage，打樁埋點，驗證結果