理解unittest测试框架（六）阶段性总结

背景

前几篇文章介绍了unittest测试框架的实现逻辑。本文做一个简单的总结。

框架设计

首先，框架设计上遵循着模块设计的原则，把这个框架分为了几大类。他们分别为：框架入口，结果类，执行类，测试加载类，测试用例类和测试套件类。

这里比较经典的运用了门面模式来组织，在我们日常的开发工作中，其实是非常值得借鉴的。

unittestflow.png

从流程上，可以看出来其实只有一个执行入口，但是对于框架的使用需求来说，有脚本式和命令式这两种使用场景，框架这里再执行入口上增加支持的场景，通过一定的规则转化后，统一调用到这个执行入口，从而避免了代码中可能存在的多个执行入口的情况。

同样的，加载用例也用了一样的方式，定义好最小执行单元后，加载的最终结果都往这里靠拢，同时为了满足日常使用的场景，给了通过名字加载，通过模块加载等方式，最终这些加载方式都会把加载的内容转换成最小执行单元。

用例执行这里用了Python中的反射原理，加载到用例的函数名后，执行时就是用这个 函数名去类中获取可执行的属性，最终通过自己的调用编排，实现了最小执行单元的执行顺序。

结果输出也有类似的影子在这里，结果的输出默认是使用系统的标准输出来输出结果，系统自己 内部的结果输出，也是通过替换这个标准输出的句柄来实现的，而unittest框架常用的测试报告，都是使用file作为句柄去替换标准输出的句柄，从而实现生成测试报告的。

最后

其实按正常的逻辑来写，这篇文章应该作为整个的开篇，但是我希望读者能真正的把这一个系列读完，并且跟着这个流程去看一看unittest的源码，因此没有把本文放到系列的一开始。我相信如果读者真的能够跟着这个系列一起看源码，我这里说到的一些总结，应该是能有一些共鸣的。

结束了吗？

当然没有，unittest是Python中最基础的测试框架，它还有很多不足，比如它并不支持参数化传入，在这点上，基于unittest框架拓展的pytest，nosetest等框架都有很好的补充，并且这些框架是完全兼容unittest的，我也想接着这个机会，一起学一下这些unittest框架的升级版。