背景：年底了技術部有人陸續離職，我負責B端業務線也有了影響，迭代速度慢了，正好趁這個時間把之前一直想改的介面框架有一個痛點改一下。之前我在寫case的時候回斷言介面的返回，一般都是response['code']的值，如果code！=0（0是rd自行約定的）assertEqual就會丟擲一個assertError的異常，這樣我就要捕獲異常，然後出發傳送簡訊和微信push的功能。那麼問題來了，因為每個case都需要斷言，每個case都需要捕獲，重複程式碼特別的多，這是一方面，另一方面我如果再加一個別的監控功能，每一個case都需要去加（之前我加微信push功能就是一個個case加的，特別蛋疼），昨天我就想重寫一個unittest.testcase類得斷言方法，需要一些坑，今天總結一下。

思路：剛開始我想的是首先寫一個AssertType類繼承unittest.testcase類，然後重寫assertEqual方法，增加捕獲異常觸發功能，然後我再case中使用重寫的asserEqual方法。覺得思路不錯然後我就去寫了，如圖：

case層繼承AssertType類，不在繼承unittest.testcase,斷言直接呼叫如圖：

這樣執行時沒有問題，但有一個問題，如果其他case需要呼叫父類assertEqual怎麼辦，其他人用起來也會用起來也會很奇怪。後來和

框架的方法重寫還是要慎重一些，後來就想到寫一個assertEqual_new方法，這樣和框架的方法就不衝突了，如圖：

斷言介面返回的value我目前就用到這兩個方法。其實我昨天寫這個時候需要好多莫名其妙的問題，今天想不起來昨天錯誤的怎麼寫的了，除錯的時候真的挺坎坷的，給大家提供一個思路，case層能抽離就抽離出去，不要太多冗餘的程式碼，這樣以後維護起來也方便。

我昨天還想著要不然直接把框架原始碼改了就是如圖這塊：

直接把捕獲的程式碼放到這裡面，但是我不知道怎麼把觸發功能的包倒過去，然後去和rd聊了一下，他說改原始碼大忌絕對不行，坑一大推，後來想想也是，畢竟是官方自帶的瞎改不知道會遇到啥問題。大家引以為戒吧