从 coverage.py 运行测试与从测试运行器运行覆盖答案

【问题标题】：Running tests from coverage.py vs running coverage from test runner从 coverage.py 运行测试与从测试运行器运行覆盖
【发布时间】：2016-11-09 06:36:39
【问题描述】：

在Coverage.py with Ned Batchelder python&testing 播客中，Brian 和 Ned 简要讨论了，如果您需要运行覆盖率测试，最好从 coverage.py 运行测试 执行 coverage run 为反对使用覆盖率调用测试运行器。为什么会这样，有什么区别？

为此添加一些上下文：目前我正在使用nose 测试运行器并在nosetests 命令行工具和--with-coverage option 的帮助下执行测试：

$ nosetests --with-coverage --cover-html

我应该通过coverage run -m 来代替吗？

$ coverage run -m nose
$ coverage report

【问题讨论】：

我不知道这是否正确（所以我没有把它作为答案发布），但我的直觉是，如果你直接使用覆盖，那么你关心的是覆盖，和鼻子，你没有插件的额外依赖。耦合更少，要跟踪的版本也更少。
"invoking a test runner with coverage"——你没有明确说明你在说什么测试运行器（也许他们也没有在播客上——我没有列出来）。我想对于测试运行器案例，您相信测试运行器会在正确的时间启动覆盖机制（例如，在导入要测试的东西之前）。如果您直接调用coverage，那么您就知道一切都设置为从一开始就使用coverage，并且每一行都将按照您的意愿进行跟踪。

标签： python unit-testing testing code-coverage coverage.py

【解决方案1】：

我想我是唯一有资格回答这个问题的:)

mwchase 和 mgilson 在他们的 cmets 中有正确的做法：使用插件意味着您依赖于该插件的行为是否正确且易于理解。以提供帮助的名义，插件将有自己的逻辑，这在编写它们时可能是最好的主意，但同时测试运行程序和/或 coverage.py 可能已经改变。插件往往不像其他组件那样维护得很好。如果你能避免它们，你就少了一件需要考虑的事情。

真实的事实：我首先添加对 .coveragerc 配置文件的支持的原因是因为我想向 coverage.py 添加功能并且不想等待插件 UI 更新以支持它们。

【讨论】：

出于某种原因，互联网上的大多数“如何使用nose/pytest with coverage”命令示例都展示了如何使用带有覆盖插件的跑步者，而没有提到你也可以使用@ 987654321@，这通常是一个更好的方法。再次感谢！