接口测试-工作心得记录六(重写unittest断言类)
背景:年底了技术部有人陆续离职,我负责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聊了一下,他说改源码大忌绝对不行,坑一大推,后来想想也是,毕竟是官方自带的瞎改不知道会遇到啥问题。大家引以为戒吧