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

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

1. 保持測試代碼的緊湊和可讀性

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

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

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

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

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

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

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

4. 不要Mock你不擁有的類型！

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

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

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

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

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

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

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

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

不要Mock值對象

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

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

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

  public static Customer customer_with_a_single_item_in_the_basket() {
　　       // long init sequence
　　   }
　　}

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

感謝每一個認(rèn)真閱讀我文章的人，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：

這些資料，對于【軟件測試】的朋友來說應(yīng)該是最全面最完整的備戰(zhàn)倉庫，這個倉庫也陪伴上萬個測試工程師們走過最艱難的路程，希望也能幫助到你!有需要的小伙伴可以點(diǎn)擊下方小卡片領(lǐng)取?

?文章來源地址http://www.zghlxwxcb.cn/news/detail-848395.html

到了這里，關(guān)于攜程大牛的單元測試是怎么樣寫的？的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！