我們都知道，持續(xù)交付的流程包括如下幾個步驟，
開發(fā) -> 單元測試(覆蓋率) -> 合并代碼 -> 集成測試(自動化回歸) -> 上線(持續(xù)部署)

之前做運(yùn)維的時候，我更多關(guān)注的是從集成測試到上線的部分，做持續(xù)部署。現(xiàn)在作為研發(fā)，更多關(guān)注的是從開發(fā)到集成測試的部分。有效的測試可以極大避免bug出現(xiàn)在生產(chǎn)環(huán)境。而在測試中最底層，最重要的就是單測。

一、單元測試

如何界定測試的單元? 我理解單元基本可以等同于方法，所以在統(tǒng)計單測覆蓋率的時候，會有單測類覆蓋率、方法覆蓋率、行覆蓋率等。當(dāng)然，單測也可以是一組方法，甚至涉及到多個類的多個方法，這都不強(qiáng)制規(guī)定。
單測的最主要目的是用來發(fā)現(xiàn)測試未覆蓋的代碼。單測覆蓋率高不能說明代碼質(zhì)量高，但覆蓋率低一定說明代碼風(fēng)險較大。一般而言，方法覆蓋率至少到80%，除一些非常簡單的方法外。
在項目開發(fā)比較緊張的時候，或要快速出原型的時候，可以不寫單測，但記住，這一定屬于技術(shù)債務(wù)，需要及時補(bǔ)上，否則在后續(xù)重構(gòu)、升級的時候，很可能引入其他問題，把代碼改壞。

1.1 單元測試的基本套路

一個單元測試的核心有4步，準(zhǔn)備數(shù)據(jù) -> 執(zhí)行測試邏輯 -> 斷言 -> 清理數(shù)據(jù)
數(shù)據(jù)準(zhǔn)備與清理，可能會涉及到的注解有@BeforeClass, @AfterClass, @Before, @After，說明下@BeforeClass和@Before的區(qū)別，另外一對類似。

• @BeforeClass只執(zhí)行一次，必須標(biāo)注在類方法上(static void method)。
• @Before在每個測試方法前都會執(zhí)行，標(biāo)注在成員方法上。

1.2 如何設(shè)計單元測試

單元測試要盡量覆蓋代碼分支，最好為每一個場景，每一個分支寫一個單測。并且需要模擬一些異常場景，比如調(diào)用某一個外部服務(wù)出現(xiàn)異常了，你期望的結(jié)果是什么，代碼執(zhí)行是否符合預(yù)期。
但現(xiàn)實很骨感，往往讓“為每一種場景寫單測”變得不現(xiàn)實。比如在寫的時候會發(fā)現(xiàn)有各種問題，比如，怎么能模擬到某一個異常分支，或者怎么模擬一個異常拋出來，搞出臟數(shù)據(jù)怎么辦?等等。
這時就可以用一些mock的方法，把一些危險/比較重的操作給模擬掉。將測試的重點(diǎn)放到業(yè)務(wù)邏輯上。

1.3 單測的命名

對于命名，我向來比較糾結(jié)。起一個好的名字可以很好地幫助別人理解你的意圖。
對于單測，我自己的訴求是，首先我想知道自己測的是哪個方法，其次我想知道在什么條件下，最后我想知道出現(xiàn)的結(jié)果是否符合預(yù)期。
所以，我個人比較傾向于<method>_should_<expected>_when_<condition> 這種命名方式。看起來比較清晰。
但如果你重命名了method，那就需要手動改下單測了.. 沒有一個IDE的refactor可以直接把單測的相關(guān)方法中method也改掉..