不管是哪種測試，都是為了確保程式碼的品質，以及是否符合需求規格。而單元測試是工程師確保自身產出的一種方式，怎麼確定自己寫的單元測試涵蓋所有的函式呢？

以 Android Studio 是提供了行數、類別和函式數單元測試覆率計算。但每一個開發團隊對於覆蓋率的定義都不一樣，但是先問問你自己寫單元測試是為了什麼？

寫了這些測試，未來邏輯異動是不是也能確保這些內容無誤，畢竟寫了這些程式碼將來就是會有維護的成本。所以考慮覆蓋率的同時，不妨也考量後續的維護成本。

最後，重構之前要不要寫單元測試保護確保邏輯。通常說出這句話的，有兩種情境：

一、原有邏輯沒有單元測試：依需要重構的狀況，有些邏輯可以包進物件裡、邏輯優化、架構改善或是換其他程式語言做改寫等等。像邏輯包進物件裡，就很適合在重構前先進行驗證。

二、原有邏輯亂到沒人想要了解邏輯如何運作：工程師面臨大挑戰，有些時候不是想慢慢拆，而是它本身就是個隕石坑，誰踩到就爬不出來。

如果有測試團隊可能還可以從測試情境中撈出一些驗證條件做輔助。

若沒有就只能考量是不同的階段進行優化，但一步步進行雖然沒辦法看到很大的改變，可是卻是最穩的做法，只是考驗大家的耐性，以及團隊對技術債給予的空間。

相信在技術債上是很多開發團隊的痛，而這些痛通常都得過且過，但只到他大爆炸的時候，反而會讓開發團隊處於緊張跟壓力巨大的困境之中。

與其讓他將來有機會發生，不如讓它早早被看見被處理，讓每一天好好工作不用擔心是不是有未爆彈。