189 8069 5689
本篇内容介绍了“python第三方库Coveralls ”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
网站建设哪家好，找创新互联！专注于网页设计、网站建设、微信开发、重庆小程序开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了川汇免费建站欢迎大家使用！
前两天在 GitHub 浏览 Python 的三方库时，看到了以下
就像 https 那个绿色锁的标志一样，看着很可信，让人用着放心，很多开源项目都有这些图标。
看到 coverage 是 98%，我产生了疑问，这是手工统计的，还是程序自动测试出来的呢?
如果是手工统计的，肯定都往高了写，这样的数据也就没有价值，如果是程序自动测试出来的，想着都觉得复杂，是怎么实现的呢?带着这些疑问，我点击了那个 coverage 98%，跳转到了 https://coveralls.io/ 的页面。
探索了一番，发现原来这是叫 coveralls 的三方库实现的，用于在线实时显示单元测试的覆盖率，测试数据是通过 coverage 来跑出来的。
好奇的我 pip install 安装了下，拿自己之前的程序，写了几个单元测试，用了下这两条命令：
coverage run --source=dbinterface -m pytest tests/ coverage report -m
发现，这个单元测试的覆盖率果然是程序自动统计出来的，coverage 真的太牛了，有了这个，写单元测试就无法偷懒了，代码质量就有了量化标准。
从上面的图中可以看到文件的哪些代码行没有测试到，然后针对性的编写单元测试。还可以生成 html 文件进行查询，更为直观。
猜测 coverage 应该是记录了 pytest 调用的代码行数，然后从全部代码行记录中去除已经测试过的行记录，就是未测试的代码行，从而统计覆盖率。
当时，我不由自主发出了‘卧槽牛批’，不过仍然有疑问，程序是怎么检测哪些代码行被执行了呢?虽然我知道 debug 时可以看到，但是如何写程序统计，我还一无所知。
好奇心驱使着我去探索。
首先看下这个 coverage 来自哪里，里面有什么内容：
(py38env) ? dbinterface git:(master) ? which coverage /Users/aaron/py38env/bin/coverage
可以看到 coverage 的内容：
(py38env) ➜ dbinterface git:(master) ✗ cat /Users/aaron/py38env/bin/coverage #!/Users/aaron/py38env/bin/python3 # -*- coding: utf-8 -*- import re import sys from coverage.cmdline import main if __name__ == '__main__': sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0]) sys.exit(main()) (py38env) ➜ dbinterface git:(master) ✗
其实，在命令行执行 coverage，就相当于执行：
/Users/aaron/py38env/bin/python3 coverage
将该文件保存到一个目录中，命名为 main.py，然后使用 PyCharm IDE 开始调试，调试的过程中，发现 coverage run --source=dbinterface -m pytest tests/ 命令会将测试的结果写入到文件 .coverage 中，再执行 coverage report -m 时会从该文件统计出覆盖率。
也就是说关键是要弄清楚命令 coverage run --source=dbinterface -m pytest tests/ 的执行过程。
继续 Debug，这里说下，由于我们的命令是在路径 /Users/aaron/github/somenzz/dbinterface 下执行的，在 Debug 前，先使用 os.chdir 改变程序的工作目录：
main.py
#!/Users/aaron/py38env/bin/python3 # -*- coding: utf-8 -*- import re import sys from coverage.cmdline import main import os if __name__ == '__main__': os.chdir('/Users/aaron/github/somenzz/dbinterface') sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0]) print(sys.argv[0]) sys.exit(main())然后加入参数，打好断点，追踪。
最后追踪到这里：
这里的 tracer 类就是 CTracer，其源头可以从 collector.py 文件的这段代码看出来：
可以看出 tracer 的原型要么是 CTracer， 要么是 PyTracer。
从作者的注释中可以看到 CTracer 速度非常快，而 PyTracer 相对较慢。
想看 CTracer 的源代码，结果发现了这个文件
.so 文件相当于 windows 的 dll 文件，是动态链接库，需要反编译成汇编语言，然后再分析执行逻辑，这个对我来说太难了，自己又不熟悉汇编，于是放弃。
那就只剩下 PyTracer 了，原理应该是类似的，PyTracer 的源代码就是 pytracer.py 文件，可以直接打开查看。
文件开始的地方，导入了以下三个库：
import atexit import dis import sys from coverage import env
其中前三个都是标准库，atexit 是退出处理器，可以注册一个函数，在解释器终止时执行。dis 是 Python 字节码反汇编器，这两个的使用只有一次，没有派上大用处，可以忽略。
重点就是第三个 sys 模块，这个模块和 os 模块可以说是博大精深，很多程序都会使用到，从包的名称也可以总结规律，名字越短，就越重要，其使用频率就越高。
看 PyTracer 源代码, sys.settrace 是起决定作用的，是 coverage 能够统计单元测试覆盖率的关键。
下面是对 Python 官方文档对 sys.settrace 的介绍：
sys.settrace(tracefunc) 用来设置系统的跟踪函数，使得用户在 Python 中就可以实现 Python 源代码调试器。该函数是特定于单个线程的，所以要让调试器支持多线程，必须为正在调试的每个线程都用 settrace() 注册一个跟踪函数，或使用 threading.settrace()。
跟踪函数应接收三个参数：frame、event 和 arg。frame 是当前的堆栈帧。event 是一个字符串：'call'、'line'、'return'、'exception' 或 'opcode'。arg 取决于事件类型。
官方文档 bb 这么多，说实话我也没太懂，到底咋用呢?我网上找了一个例子，比如说文件 trace.py 内容如下：
import sys def stuff(): print("calling stuff") def printer(frame, event, arg): print(frame, event, arg) return printer # return itself to keep tracing sys.settrace(printer) stuff()也就是说执行函数之前，加上 sys.settrace。执行该文件，可以得到以下结果：
