當我們談論Unit Test時我們在談論什么？(2)

具有算法和業務邏輯的代碼。這部分代碼我們應該重點關注，最為典型的就是一些公共類，基礎Service層等。盡量為它們寫上詳盡的UT，造福后人。
最后一類是非常復雜的代碼。各種復雜邏輯交織在一起，牽一發而動全身，我們本能地可以感覺到代碼中的“壞味道”。對于這類代碼，首先應該考慮做代碼的清理工作（由粗到細重構），過程中不斷為小單元注入Unit Test，最后形成一張嚴密的代碼保護網，將原來的代碼切碎為可維護的代碼。
在實際開發中對第四點可能有些爭議。對于公司或者團隊來講，一個產品的代碼不可能始終是一個人負責，但往往新的同事接手老代碼時不知道從哪下手。我的第一份工作，當我作為一個畢業生，第一次接手一個完整的項目代碼，一上來就是一個好幾千行的函數，其中包含的各種請求的發送，變量的隨意命名與重復使用，還有各種復制粘貼的痕跡。你能想象對于一個新人來講這是多么的絕望嗎。
作為一個實際寫代碼的Coder，老代碼能不碰就不碰---我舉雙手贊成，既沒有UT，邏輯又混在一起，天知道改完以后會出什么Bug。
但是對于團隊來講，如果明確知道這個模塊無法測試、無法被很好的修改，那么是時候把這部分代碼提上重構的日程了。
其實我認為代碼的組織與規范（包括UT）是開發流程中非常重要的一部分，在一開始我們就應該定期進行CodeReview，避免寫出無法維護的代碼。一個團隊可能會負責多個項目，這些項目應該是屬于團隊中的每一個人，而不是誰負責，其他人就可以不管。我們應該把項目的Dev和Ops視為自己的責任。有太多的項目由于走形式的CodeReview、沒有UT、沒有文檔，導致最后無法維護，這是我們都不想看到的。
UT是不可能寫的，這輩子都不可能寫的，老代碼就只能讓它勉強運行下去這樣子~
四. 怎么做Unit Test
至于如何做UT，網上一搜一大把的教程，這里就不贅述了，只是列幾條個人總結的值得注意的點：
多組數據（考慮周全）->正常業務測試，邊界條件測試
不要誤用Mock工具，理清需要被Mock的對象
整體覆蓋率沒有意義，但是關鍵業務代碼覆蓋率很重要
運維時：每一個BugReport都應有一個對應的UT
UT并不是越多越好，而是對于核心代碼、有意義的錯誤，UT越詳細越好

原文轉自：https://www.jianshu.com/p/8e11c8fa63af