Python 代码覆盖率和多处理答案

【问题标题】：Python Code Coverage and MultiprocessingPython 代码覆盖率和多处理
【发布时间】：2015-04-02 13:34:03
【问题描述】：

我将coveralls 与coverage.py 结合使用来跟踪我的测试脚本的python 代码覆盖率。我使用以下命令：

coverage run --parallel-mode --source=mysource --omit=*/stuff/idont/need.py ./mysource/tests/run_all_tests.py
coverage combine
coveralls --verbose

除了multiprocessing 之外，这非常有效。由工作池或子进程执行的代码不会被跟踪。

是否有可能同时跟踪多处理代码？我缺少任何特定的选项吗？每次产生一个新进程时，也许将包装器添加到多处理库以开始覆盖？

编辑：

我（还有 jonrsharpe，也 :-）找到了 monkey-patch for multiprocessing。

但是，这对我不起作用，我的 Tracis-CI 构建几乎在开始后就被杀死了。我在本地机器上检查了问题，显然将补丁添加到多处理会破坏我的记忆。使用此修复程序的内存远少于 1GB 的测试需要超过 16GB。

EDIT2：

猴子补丁在稍作修改后确实可以工作：删除 config_file 解析 (config_file=os.environ['COVERAGE_PROCESS_START']) 成功了。这解决了内存膨胀的问题。因此，相应的行就变成了：

cov = coverage(data_suffix=True)

【问题讨论】：

不直接测试那些子进程的代码吗？
嗯，是的，大部分都是我做的。但是有些部分仅在使用多处理时才有用并且仅在使用多处理时执行（例如使用锁或多处理队列包装数据库访问以强制执行串行数据存储）。而且我自己知道，由于测试成功，这段代码可以正常工作。如果这也能出现在工作服上那就太好了:-)
见bitbucket.org/ned/coveragepy/issue/117/…，通过nedbatchelder.com/code/coverage/trouble.html
谢谢，我也偶然发现了这个。但是，猴子补丁对我不起作用。将此添加到我的脚本中几乎会立即杀死我构建的 Travis-CI。我也在我的本地机器上检查了这个。显然，猴子补丁破坏了我的记忆。 Coverage 为通常需要远低于 1GB 的测试分配超过 16GB 的内存。
@SmCaterpillar 我很想听听您的经历。删除配置文件解析的想法似乎很奇怪：我无法想象解析配置文件会如何从根本上改变内存占用。 COVERAGE_PROCESS_START 对您来说有什么价值？你有 .coveragerc 文件吗？如果您想深入了解，请给我发电子邮件。

【解决方案1】：

Coverage 4.0 包含一个命令行选项--concurrency=multiprocessing 来处理这个问题。之后您必须使用coverage combine。例如，如果您的测试在 regression_tests.py 中，那么您只需在命令行中执行此操作：

coverage run --concurrency=multiprocessing regression_tests.py
coverage combine

【讨论】：

感谢您指出之后使用coverage combine 的要求。我一直在旋转我的轮子，试图弄清楚为什么我在.coveragerc 文件中的concurrency=multiprocessing 不起作用。
您能否在此答案中添加一个简单的基本示例？这对我有很大帮助。
@LucaCappelletti 完成；希望有帮助。

【解决方案2】：

我花了一些时间尝试确保覆盖范围适用于 multiprocessing.Pool，但它从未奏效。

我终于做了一个修复，让它工作 - 如果有人指导我，如果我做错了什么，我会很高兴。

【讨论】：

我相信这里的链接可能会对您有所帮助：pytest-cov.readthedocs.io/en/latest/… - 看来您需要在线程中调用 join 以避免一些问题。
非常感谢戴维斯 - 几年后我一直想念那个。 :)