使用斷言的最佳時機偶爾會被提起，通常是因為有人誤用，因此我覺得有必要寫一篇文章來闡述一下什麼時候應該用斷言，為什麼應該用，什麼時候不該用。

對那些沒有意識到用斷言的最佳時機的人來說，Python的斷言就是檢測一個條件，如果條件為真，它什麼都不做；反之它觸發一個帶可選錯誤資訊的AssertionError。如下例所示：

很多人將斷言作為當傳遞了錯誤的引數值時的一種快速而簡便的觸發異常的方式。但實際上這是錯誤的，而且是非常危險的錯誤，原因有兩點。首先，AssertionError通常是在測試函式引數時給出的錯誤。你不會像下面這樣編碼：

你應該用TypeError來替代，“斷言”解決了錯誤的異常型別。

但是對斷言來說更危險也更糾結的是：如果你執行Python時使用了-O或-OO優化標識，這能夠通過編譯卻從來不會被執行，實際上就是說並不能保證斷言會被執行。當恰當地使用了斷言，這非常好的，但當不恰當地使用了斷言，在使用-O標識執行時它將導致程式碼被徹底中斷。

那麼我們什麼時候應該使用斷言呢？如果沒有特別的目的，斷言應該用於如下情況：

• 防禦性的程式設計
• 執行時對程式邏輯的檢測
• 合約性檢查（比如前置條件，後置條件）
• 程式中的常量
• 檢查文件

（斷言也可以用於程式碼測試，用作一個做事毛手毛腳的開發人員的單元測試，只要能你接受當使用-O標誌時這個測試什麼都不做。我有時也會在程式碼中用"assert Fasle"來對還沒有實現的分支作標記，當然我希望他們失敗。如果稍微更細節一些，或許觸發NotImplementedError是更好的選擇）

因為程式設計師是對於程式碼正確性表現出的信心不同，因此對於什麼時候使用斷言的意見各不相同。如果你確信程式碼是正確的，那麼斷言沒有任何意義，因為它們從不會失敗，因此你可以放心地移除它們。如果你確信它們會失敗（例如對使用者輸入的資料的檢測），你不敢用斷言，這樣編譯就能通過，但你跳過了你的檢查。

在以上兩種情況之間的情況就顯得特別有趣了，那就是當你相信程式碼是正確的，但又不是特別確定的時候。或許你忘記了一些奇怪的邊角情況（因為我們都是人），在這種情況下，額外的執行時檢查將幫助你儘可能早地捕獲錯誤，而不是寫了一大堆程式碼之後。

（這就是為什麼使用斷言的時機會不同。因為我們對程式碼正確性的資訊不同，對於一個人有用的斷言，對於另一個人來說卻是無用的執行時測試。）

另一個斷言用得好的地方就是檢查程式中的不變數。一個不變數是一些你能相信為真的條件，除非一個缺陷導致它變成假。如果有一個缺陷，越早發現越好，因此我們需要對其進行測試，但我們不想因為這些測試而影響程式碼執行速度。因此採用斷言，它能在開發時生效而在產品中失效。

一個關於不變數的例子可能是這樣的情況。如果你的函式在開始的時候期望一個開啟的資料庫連線，並且在函式返回後該資料庫連線依然是開啟的，這是一個函式的不變數：

斷言也是一個很好的檢查點註釋。為了替代如下注釋：

#當我們執行到這裡，我們知道n>2

你可以確保在執行時用以下斷言：

斷言也是一種防禦性的程式設計形式。你不是在防範當前程式碼發生錯誤，而防範由於以後的程式碼變更發生錯誤。理想情況下，單元測試應該直到這個作用，但是讓我們面對這樣一個現實：即使存在單元測試，他們在通常情況下也不是很完備。內建的機器人可能沒有工作，但數週以來也沒有人注意到它，或者人們在提交程式碼之前忘記了執行測試。內部檢查將是防止錯誤滲入的另一道防線，尤其對於那些悄悄地失敗，但會引起程式碼功能錯誤並返回錯誤結果的情況有效。

假設你有一系列的if...elif程式碼塊，你預先知道變數期望的值：

假設這段程式碼現在完全正確。但它會一直正確嗎？需求變更，程式碼變更。如果需求變為允許target = w，並關聯到run_w_code，那將會發生什麼情況？如果我們變更了設定target的程式碼，但是忘記了改變這個程式碼塊，它就會錯誤地呼叫run_z_code()，錯誤就會發生。對於這段程式碼最好的方法就是編寫一些防禦性的檢查，這樣它的執行，即使在變更以後，要麼正確，要麼馬上失敗。

在程式碼開始添加註釋是個好的開端，但是人們都不太喜歡讀和更新這些註釋，這些註釋會很快變得過時。但對於斷言，我們可以同時對這塊程式碼編寫文件，如果這些斷言被違反了，會直接引起一個簡單而又直接的失敗。

這裡的斷言同時用於防禦性程式設計和檢查文件。我認為這是最優的解決方案：

這誘使開發者去不理程式碼，移除像value ==c這類不必要的測試，以及RuntimeError的“死程式碼”。另外，當"unexpected error"錯誤發生時這個訊息將非常窘迫，確實會發生。

合約式設計是斷言另一個用得好的地方。在合約式設計中，我們認為函式與其他呼叫者遵循合約，例如像這樣的情況：

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

如果合約被破壞了，不管是被函式本身還是呼叫者，這都會產生缺陷。我們說這個函式需要有前置條件（對期望的引數的限制）和後置條件（對返回結果的約束）。因此這個函式可能是這樣的：

合約式設計的目的是，在一個正確的程式裡，所有的前置條件和後置條件都將得到處理。這是斷言的經典應用，自（這個想法持續）我們釋出無缺陷的程式並且將其放入產品，程式將是正確的並且我們可以放心地移除檢查。

這裡是我建議不使用斷言的情況：

*不要用於測試使用者提供的資料，或者那些需要在所有情況下需要改變檢查的地方

*不要用於檢查你認為在通常使用中可能失敗的地方。斷言用於非常特別的失敗條件。你的使用者絕不看到一個AssertionError，如果看到了，那就是個必須修復的缺陷。

*特別地不要因為斷言只是比一個明確的測試加一個觸發異常矮小而使用它。斷言不是懶惰的程式碼編寫者的捷徑。

*不要將斷言用於公共函式庫輸入引數的檢查，因為你不能控制呼叫者，並且不能保證它不破壞函式的合約。

*不要將斷言用於你期望修改的任何錯誤。換句話，你沒有任何理由在產品程式碼捕獲一個AssertionError異常。

*不要太多使用斷言，它們使程式碼變得晦澀難懂。