2.3.2　斷言的時機

到底什么時候使用斷言比較好呢？可以從開發和測試兩個方面為大家簡單介紹斷言的時機及不使用斷言的情況。

開發人員　通常在下面時機點添加斷言（本書以測試為主，對開發只做簡單介紹）：

• 防御性地編程，也就是不滿足條件時直接顯示失敗。示例代碼如下：

上述代碼，當target為x時運行run_x_code（）;當target為y時運行run_y_code（）;當target為其他情況時運行else中的代碼，也就是target如果為z，則運行run_z_code（）;如果不是上述內容，會直接引起一個簡單而又直接的失敗。

• 運行時對程序邏輯檢測；
• 合約性檢查（例如前置條件、后置條件）；

例如：“如果你傳給筆者一個非空字符串，筆者保證返回首字母轉換成大寫的字符串。”

• 程序中的常量；
• 檢查文檔。

測試人員　通常對所有需要比對的需求及功能進行驗證時使用斷言，下面分析一下斷言的主要時機點：

• 驗證頁面是否跳轉到正確的頁面；
• 驗證計算結果與正確結果是否一致；
• 驗證類型是否一致；
• 驗證添加功能是否成功添加；
• 驗證接口返回的JSON數據是否正確；
• 驗證接口返回的狀態碼是否正確；
• 驗證接口性能是否在范圍內；
• 驗證元素是否已被選擇；
• 驗證元素是否為不可操作；
• 驗證返回值是否與預期一致。

不使用斷言的幾種情況：

• 不要用于測試用戶提供的數據，或者那些在所有情況下需要改變檢查的地方；
• 不要用于檢查你認為在通常使用中可能失敗的地方；
• 用戶絕看不到一個AssertionError，如果看到了，那就是必須修復的缺陷；
• 特別地不要因為斷言只比一個明確的測試加一個觸發異常簡單而使用它。斷言不是懶惰的代碼編寫者的捷徑；
• 不要將斷言用于公共函數庫輸入參數的檢查，因為用戶不能控制調用者，并且不能保證它不破壞函數的執行；
• 不要將斷言用于用戶期望修改的任何地方。換句話，用戶沒有任何理由在產品代碼中捕獲一個AssertionError異常；
• 不要太多使用斷言，它們將使代碼變得晦澀難懂。