大家都知道，開發軟體的時候為代碼撰寫單元測驗是很好的，但實際上，光有測驗還不夠，還要撰寫好的測驗，這同樣重要，
要做到這一點，考慮遵循一些固執的原則，對測驗代碼給予一些關愛：
1. 保持測驗代碼的緊湊和可讀性
要做到這一點，應該要進行毫不留情的重構，就像對生產代碼應該做的那樣，否則讓測驗代碼隨著時間腐化，就是在測驗里面制造可怕的遺留代碼，如果測驗不能很容易重構，那么生產代碼也很難重構，從而導致生產系統的遺留代碼，始終做一個勇敢的重構者，
2. 避免撰寫重復累贅的斷言
舉個例子，測驗代碼使用正則運算式生成內容，而這個正則運算式是跟生產代碼的決議器中使用的一模一樣的，
一般來說，我們不希望在測驗和代碼之間復制邏輯，因此，在測驗中復制正則運算式或其他內容不是一種選擇，在這種情況下，考慮測驗輸入激勵/輸出結果之間的關系（f（輸入） - >輸出）可能會有幫助，例如，如果代碼的目標是要做模板替換，不要在測驗代碼里用原始值來做替換，相反，在測驗里面直接指定預期的計算結果，
// 使用
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. 覆寫盡可能多的范圍，包括正面情況，以及（甚至更重要的）出錯的代碼路徑，
通常，要做到這一點，最好的辦法試采用測驗驅動開發（Test Driven Development），通過TDD，人們可以在設計時識別可能會出錯的部分，不要羞于為一段小代碼撰寫一個簡單的測驗用例，你永遠不知道什么時候，為什么以及以什么方式，你會要用到甚至修改這段代碼，
可以研究一下如何檢查測驗的有效性，類似PIT這樣的工具可以進行變更測驗，值得研究一下，
4. 不要Mock你不擁有的型別！
這不是一個硬界限，但越過這條線很可能會產生反作用力！
TDD是關于設計的，也是關于測驗的，兩者一樣重要，在模擬外部API時，測驗不能用于驅動設計，API屬于第三方；這個第三方可以，并且實際上也經常會更改API的簽名和行為，
想象一下Mock第三方Lib的代碼，在第三方庫的某次升級之后，它的邏輯可能會改變，但測驗套件仍會執行得很好，因為它被Mock了，所以后來，你認為一切都很好，畢竟構建墻是綠色的，軟體部署上去，然后......嘣
如果你感覺需要Mock第三方庫，可能表明你當前的設計與第三方庫沒有足夠的分離，
另一個問題是第三方庫可能很復雜，需要大量的Mock才能正常作業，這導致過度指定的測驗和復雜的測驗輔助裝置，這本身就損害了緊湊和可讀的目標，或者由于模擬外部系統過于復雜，從而導致測驗代碼對生產代碼的覆寫不足，
取而代之的最常見的方法，是圍繞外部lib / 系統創建包裝器，盡管應該意識到抽象泄漏的風險，其中過多的低級API，概念或例外超出了包裝器的邊界，為了驗證與第三方庫的集成，撰寫集成測驗，并使它們盡可能緊湊和可讀，
5. 不要Mock一切，這是一種反模式
如果一切都被Mock，我們真的在測驗生產代碼嗎？該不Mock的時候，不要猶豫！
不要Mock值物件
為什么人們甚至想要這樣做？
因為實體化物件太痛苦了！ => 不是正當理由，
如果創建新的物件太難了，那么代碼可能需要一些嚴肅的重構，另一種方法是為您的值物件創建構建器 - 有一些工具，包括IDE插件，Lombok和其他，還可以在測驗類路徑中創建有意義的工廠方法，
abstract class CustomerCreations {
public static Customer customer_with_a_single_item_in_the_basket() {
// long init sequence
}
}
Mockito專注于物件之間的相互操作，這是面向物件編程的核心部分，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/92589.html
標籤：Python
上一篇：Java的重寫