大家都知道琳猫，開發(fā)軟件的時(shí)候?yàn)榇a編寫單元測試是很好的。但實(shí)際上私痹，光有測試還不夠沸移，還要編寫好的測試痪伦，這同樣重要。
要做到這一點(diǎn)雹锣，考慮遵循一些固執(zhí)的原則网沾，對測試代碼給予一些關(guān)愛：
1. 保持測試代碼的緊湊和可讀性
要做到這一點(diǎn)，應(yīng)該要進(jìn)行毫不留情的重構(gòu)蕊爵，就像對生產(chǎn)代碼應(yīng)該做的那樣辉哥。否則讓測試代碼隨著時(shí)間腐化，就是在測試?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));
復(fù)制代碼
3. 覆蓋盡可能多的范圍冕象，包括正面情況，以及（甚至更重要的）出錯的代碼路徑酣衷。
通常交惯，要做到這一點(diǎn)，最好的辦法試采用測試驅(qū)動開發(fā)（Test Driven Development）穿仪。通過TDD席爽，人們可以在設(shè)計(jì)時(shí)識別可能會出錯的部分。不要羞于為一段小代碼編寫一個簡單的測試用例啊片。你永遠(yuǎn)不知道什么時(shí)候只锻，為什么以及以什么方式，你會要用到甚至修改這段代碼紫谷。
如果對軟件測試齐饮、接口測試捐寥、自動化測試、性能測試祖驱、LR腳本開發(fā)握恳、面試經(jīng)驗(yàn)交流。感興趣可以273462828捺僻，群內(nèi)會有不定期的發(fā)放免費(fèi)的資料鏈接乡洼，這些資料都是從各個技術(shù)網(wǎng)站搜集、整理出來的匕坯，如果你有好的學(xué)習(xí)資料可以私聊發(fā)我束昵，我會注明出處之后分享給大家。
可以研究一下如何檢查測試的有效性葛峻，類似PIT這樣的工具可以進(jìn)行變更測試锹雏，值得研究一下。
4. 不要Mock你不擁有的類型术奖！
這不是一個硬界限礁遵，但越過這條線很可能會產(chǎn)生反作用力！
TDD是關(guān)于設(shè)計(jì)的腰耙，也是關(guān)于測試的榛丢，兩者一樣重要铲球，在模擬外部API時(shí)挺庞，測試不能用于驅(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)艘款。或者由于模擬外部系統(tǒng)過于復(fù)雜沃琅，從而導(dǎo)致測試代碼對生產(chǎn)代碼的覆蓋不足哗咆。
取而代之的最常見的方法，是圍繞外部lib / 系統(tǒng)創(chuàng)建包裝器益眉，盡管應(yīng)該意識到抽象泄漏的風(fēng)險(xiǎn)岳枷，其中過多的低級API，概念或異常超出了包裝器的邊界呜叫。為了驗(yàn)證與第三方庫的集成空繁，編寫集成測試，并使它們盡可能緊湊和可讀朱庆。
5. 不要Mock一切盛泡，這是一種反模式
如果一切都被Mock，我們真的在測試生產(chǎn)代碼嗎娱颊？該不Mock的時(shí)候傲诵，不要猶豫！
不要Mock值對象
為什么人們甚至想要這樣做箱硕？
因?yàn)閷?shí)例化對象太痛苦了拴竹！ => 不是正當(dāng)理由。
如果創(chuàng)建新的對象太難了剧罩，那么代碼可能需要一些嚴(yán)肅的重構(gòu)栓拜。另一種方法是為您的值對象創(chuàng)建構(gòu)建器 - 有一些工具，包括IDE插件惠昔，Lombok和其他幕与。還可以在測試類路徑中創(chuàng)建有意義的工廠方法。
abstract class CustomerCreations {
public static Customer customer_with_a_single_item_in_the_basket() {
// long init sequence
}
}
復(fù)制代碼
Mockito專注于對象之間的相互操作镇防，這是面向?qū)ο缶幊痰暮诵牟糠帧?/p>
