背景：年底了技术部有人陆续离职，我负责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聊了一下，他说改源码大忌绝对不行，坑一大推，后来想想也是，毕竟是官方自带的瞎改不知道会遇到啥问题。大家引以为戒吧