?

大家都知道，開(kāi)發(fā)軟件的時(shí)候?yàn)榇a編寫(xiě)單元測(cè)試是很好的。但實(shí)際上，光有測(cè)試還不夠，還要編寫(xiě)好的測(cè)試，這同樣重要。

要做到這一點(diǎn)，考慮遵循一些固執(zhí)的原則，對(duì)測(cè)試代碼給予一些關(guān)愛(ài)：

1. 保持測(cè)試代碼的緊湊和可讀性

要做到這一點(diǎn)，應(yīng)該要進(jìn)行毫不留情的重構(gòu)，就像對(duì)生產(chǎn)代碼應(yīng)該做的那樣。否則讓測(cè)試代碼隨著時(shí)間腐化，就是在測(cè)試?yán)锩嬷圃炜膳碌倪z留代碼。如果測(cè)試不能很容易重構(gòu)，那么生產(chǎn)代碼也很難重構(gòu)，從而導(dǎo)致生產(chǎn)系統(tǒng)的遺留代碼。始終做一個(gè)勇敢的重構(gòu)者。

2. 避免編寫(xiě)重復(fù)累贅的斷言

舉個(gè)例子，測(cè)試代碼使用正則表達(dá)式生成內(nèi)容，而這個(gè)正則表達(dá)式是跟生產(chǎn)代碼的解析器中使用的一模一樣的。

一般來(lái)說(shuō)，我們不希望在測(cè)試和代碼之間復(fù)制邏輯。因此，在測(cè)試中復(fù)制正則表達(dá)式或其他內(nèi)容不是一種選擇。在這種情況下，考慮測(cè)試輸入激勵(lì)/輸出結(jié)果之間的關(guān)系（f（輸入） - >輸出）可能會(huì)有幫助，例如，如果代碼的目標(biāo)是要做模板替換，不要在測(cè)試代碼里用原始值來(lái)做替換。相反，在測(cè)試?yán)锩嬷苯又付A(yù)期的計(jì)算結(jié)果。

// 使用
Assertions.assertThat(processTemplate("param1", "param2")).isEqualTo("this is 'param1', and this is 'param2'"));// 而不要用
Assertions.assertThat(processTemplate("param1", "param2")).isEqualTo("this is '%s', and this is '%s'", param1, param2));
復(fù)制代碼

3. 覆蓋盡可能多的范圍，包括正面情況，以及（甚至更重要的）出錯(cuò)的代碼路徑。

通常，要做到這一點(diǎn)，最好的辦法試采用測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（Test Driven Development）。通過(guò)TDD，人們可以在設(shè)計(jì)時(shí)識(shí)別可能會(huì)出錯(cuò)的部分。不要羞于為一段小代碼編寫(xiě)一個(gè)簡(jiǎn)單的測(cè)試用例。你永遠(yuǎn)不知道什么時(shí)候，為什么以及以什么方式，你會(huì)要用到甚至修改這段代碼。

可以研究一下如何檢查測(cè)試的有效性，類(lèi)似PIT這樣的工具可以進(jìn)行變更測(cè)試，值得研究一下。

4. 不要Mock你不擁有的類(lèi)型！

這不是一個(gè)硬界限，但越過(guò)這條線很可能會(huì)產(chǎn)生反作用力！

TDD是關(guān)于設(shè)計(jì)的，也是關(guān)于測(cè)試的，兩者一樣重要，在模擬外部API時(shí)，測(cè)試不能用于驅(qū)動(dòng)設(shè)計(jì)，API屬于第三方；這個(gè)第三方可以，并且實(shí)際上也經(jīng)常會(huì)更改API的簽名和行為。

想象一下Mock第三方Lib的代碼。在第三方庫(kù)的某次升級(jí)之后，它的邏輯可能會(huì)改變，但測(cè)試套件仍會(huì)執(zhí)行得很好，因?yàn)樗籑ock了。所以后來(lái)，你認(rèn)為一切都很好，畢竟構(gòu)建墻是綠色的，軟件部署上去，然后......嘣

如果你感覺(jué)需要Mock第三方庫(kù)，可能表明你當(dāng)前的設(shè)計(jì)與第三方庫(kù)沒(méi)有足夠的分離。

另一個(gè)問(wèn)題是第三方庫(kù)可能很復(fù)雜，需要大量的Mock才能正常工作。這導(dǎo)致過(guò)度指定的測(cè)試和復(fù)雜的測(cè)試輔助裝置，這本身就損害了緊湊和可讀的目標(biāo)?；蛘哂捎谀M外部系統(tǒng)過(guò)于復(fù)雜，從而導(dǎo)致測(cè)試代碼對(duì)生產(chǎn)代碼的覆蓋不足。

取而代之的最常見(jiàn)的方法，是圍繞外部lib / 系統(tǒng)創(chuàng)建包裝器，盡管應(yīng)該意識(shí)到抽象泄漏的風(fēng)險(xiǎn)，其中過(guò)多的低級(jí)API，概念或異常超出了包裝器的邊界。為了驗(yàn)證與第三方庫(kù)的集成，編寫(xiě)集成測(cè)試，并使它們盡可能緊湊和可讀。

5. 不要Mock一切，這是一種反模式

如果一切都被Mock，我們真的在測(cè)試生產(chǎn)代碼嗎？該不Mock的時(shí)候，不要猶豫！

不要Mock值對(duì)象

為什么人們甚至想要這樣做？

因?yàn)閷?shí)例化對(duì)象太痛苦了！ => 不是正當(dāng)理由。

如果創(chuàng)建新的對(duì)象太難了，那么代碼可能需要一些嚴(yán)肅的重構(gòu)。另一種方法是為您的值對(duì)象創(chuàng)建構(gòu)建器 - 有一些工具，包括IDE插件，Lombok和其他。還可以在測(cè)試類(lèi)路徑中創(chuàng)建有意義的工廠方法。

abstract class CustomerCreations {public static Customer customer_with_a_single_item_in_the_basket() {// long init sequence}
}
復(fù)制代碼

?Mockito專(zhuān)注于對(duì)象之間的相互操作，這是面向?qū)ο缶幊痰暮诵牟糠帧?/p>