前几篇文章介绍了unittest
测试框架的实现逻辑。本文做一个简单的总结。
首先,框架设计上遵循着模块设计的原则,把这个框架分为了几大类。他们分别为:框架入口,结果类,执行类,测试加载类,测试用例类和测试套件类。
这里比较经典的运用了门面模式来组织,在我们日常的开发工作中,其实是非常值得借鉴的。
从流程上,可以看出来其实只有一个执行入口,但是对于框架的使用需求来说,有脚本式和命令式这两种使用场景,框架这里再执行入口上增加支持的场景,通过一定的规则转化后,统一调用到这个执行入口,从而避免了代码中可能存在的多个执行入口的情况。
同样的,加载用例也用了一样的方式,定义好最小执行单元后,加载的最终结果都往这里靠拢,同时为了满足日常使用的场景,给了通过名字加载,通过模块加载等方式,最终这些加载方式都会把加载的内容转换成最小执行单元。
用例执行这里用了Python中的反射原理,加载到用例的函数名后,执行时就是用这个 函数名去类中获取可执行的属性,最终通过自己的调用编排,实现了最小执行单元的执行顺序。
结果输出也有类似的影子在这里,结果的输出默认是使用系统的标准输出来输出结果,系统自己 内部的结果输出,也是通过替换这个标准输出的句柄来实现的,而unittest框架常用的测试报告,都是使用file作为句柄去替换标准输出的句柄,从而实现生成测试报告的。
其实按正常的逻辑来写,这篇文章应该作为整个的开篇,但是我希望读者能真正的把这一个系列读完,并且跟着这个流程去看一看unittest的源码,因此没有把本文放到系列的一开始。我相信如果读者真的能够跟着这个系列一起看源码,我这里说到的一些总结,应该是能有一些共鸣的。
当然没有,unittest
是Python
中最基础的测试框架,它还有很多不足,比如它并不支持参数化传入,在这点上,基于unittest
框架拓展的pytest
,nosetest
等框架都有很好的补充,并且这些框架是完全兼容unittest
的,我也想接着这个机会,一起学一下这些unittest
框架的升级版。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。