痛點
改完代碼上線后岳遥，對于改動的地方奕翔，不自測吧，可能有bug浩蓉，整體流程自測吧派继，成本又挺高，有些改動較為難覆蓋捻艳。那咋整驾窟？
很多同學這時首先會想到單測！假如我們有個理想的單測认轨，改完代碼后跑一下绅络，一切問題都解決了。
然而又引入一個新問題嘁字，如何寫單測恩急？怎么維護單測？好像沒啥思路纪蜒，最后的結(jié)果通常都是自測衷恭，或者不自測，而不是寫單測纯续。随珠。
什么是單測
什么是單測灭袁？ 這個概念很重要，理解這個概念才能設(shè)計好單測窗看。從準確的角度講茸歧，單測其實是一種細粒度的測試，能測到函數(shù)維度显沈，在單測之上软瞎，還有不同粒度的集成測試。這里要劃重點构罗，不同粒度铜涉。大家需要的其實是一種測試手段，相對比較方便的遂唧，而不一定是單測芙代，但為了講述清楚，符合大家日常的表達盖彭，下面都作為單測來說纹烹。
如何寫單測
這是大家常常討論的一個問題，據(jù)我待過的幾家公司召边，沒有哪個公司能做的非常好铺呵。單測其實是一件很難的事情，非乘砦酰考驗大家的能力片挂。
首先代碼要有良好的設(shè)計，所謂的可單測性贞盯。比如你在一個函數(shù)里音念，同時包含了一段復雜的計算邏輯，以及IO的邏輯躏敢，那么這個基本就不好測試闷愤。根據(jù)實際經(jīng)驗，要把計算邏輯件余，和IO邏輯剝離開讥脐。計算邏輯走單測的模式是可行的，至于IO邏輯啼器，建議根據(jù)實際情況旬渠，有些mock的工具，比如java里的一些mockito端壳，有些本地IO的方式坟漱，比如mysql的測試方法，或者不寫其實問題不大更哄。芋齿。
其次要注意粒度。常常有很多單測寫的特別細成翩，這個和代碼的可維護性是矛盾的觅捆。一旦代碼進行局部重構(gòu)，都極大增加了成本麻敌。應該設(shè)計合適粒度的測試用例栅炒，保證這個模塊改完后，跑下相關(guān)測試用例就可以了术羔。至于到底幾個單測赢赊，這個和代碼的復雜度，以及開發(fā)人員的水平有關(guān)级历。
最后注意覆蓋率释移，從準確性來講，應該是每個函數(shù)都有單測覆蓋寥殖，當然不意味著每個函數(shù)都是一個單測玩讳。沒有人能保證自己修改代碼不出bug，所以還是要保證至少主流程都是覆蓋的嚼贡。
結(jié)論
所以熏纯，最后終結(jié)下，寫單測不要誤入歧途粤策。不要太多樟澜，也不要太少，選擇合適的粒度叮盘，計算和IO相分離秩贰。
