从 coverage.py 运行测试与从测试运行器运行覆盖
Posted
技术标签:
【中文标题】从 coverage.py 运行测试与从测试运行器运行覆盖【英文标题】:Running tests from coverage.py vs running coverage from test runner 【发布时间】: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,并且每一行都将按照您的意愿进行跟踪。 【参考方案1】:我想我是唯一有资格回答这个问题的:)
mwchase 和 mgilson 在他们的 cmets 中有正确的做法:使用插件意味着您依赖于该插件的行为是否正确且易于理解。以提供帮助的名义,插件将有自己的逻辑,这在编写它们时可能是最好的主意,但同时测试运行程序和/或 coverage.py 可能已经改变。插件往往不像其他组件那样维护得很好。如果你能避免它们,你就少了一件需要考虑的事情。
真实的事实:我首先添加对 .coveragerc 配置文件的支持的原因是因为我想向 coverage.py 添加功能并且不想等待插件 UI 更新以支持它们。
【讨论】:
出于某种原因,互联网上的大多数“如何使用nose/pytest with coverage”命令示例都展示了如何使用带有覆盖插件的跑步者,而没有提到你也可以使用@ 987654321@,这通常是一个更好的方法。再次感谢!以上是关于从 coverage.py 运行测试与从测试运行器运行覆盖的主要内容,如果未能解决你的问题,请参考以下文章
XCTest 测试运行器在完成运行测试之前以代码 -1 退出
Coverage.py 不会发现子目录中没有 init.py 文件的测试