Cobertura 覆盖范围和assert 关键字
我的 Cobertura 测量的单元测试的行覆盖率受到影响，因为我有测试中未覆盖的 assert 语句。我应该测试断言吗？有什么方法可以让 Cobertura 忽略它们，这样它们就不会影响我的测试覆盖率？
My line coverage for unit tests measured by Cobertura is suffering, because I have assert statements which are not covered in tests. Should I be testing assertions, and is there any way to get Cobertura to ignore them so they do not affect my test coverage?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Java
assert语句的 line 覆盖率应该通过在启用断言的情况下运行测试套件来简单地覆盖，即，将 -ea 作为 jvm 的参数。如果您这样做，您会发现 cobertura 很容易报告 100% line 覆盖率（如果您的其余行也被覆盖）。
尽管如此，
assert行仍将显示为红色，表明覆盖范围不足。这是因为你的断言通常总是正确的，所以你永远不会碰到错误的分支。
因此，Cobertura 中的分支覆盖率因使用断言而变得混乱，因为断言行将具有 50% 的分支覆盖率，从而使整体分支覆盖率难以解释（或无用） 。
Clover 有一个很好的功能，可以在计算覆盖范围时忽略
assert。我还没有在任何开源 Java 覆盖率工具中看到这个功能。如果您以 design-by-contract 风格使用断言，则无需添加以下测试：使您的 Java
assert语句失败。事实上，对于许多断言（例如，不变量、后置条件），您甚至无法创建会使它们失败的对象，因此不可能编写此类测试。
不过，您可以做的是使用不变量/后置条件来派生测试用例，以行使其边界 - 请参阅 Robert Binder 的 不变边界 模式。但这并不会让你的断言失败。
仅当您对给定方法有一个非常棘手的前提条件时，您可能需要考虑编写一个旨在使前提条件失败的测试。但重新考虑一下你的前提条件可能是一个更好的主意。
The line coverage of your Java
assertstatements should be simply covered by running your test suite with assertions enabled, i.e., giving -ea as argument to the jvm.If you do this, you'll see that cobertura easily reports 100% line coverage if the rest of your lines are covered as well.
Nevertheless, the
assertlines will still be colored red, suggesting insufficient coverage.This is because your assertions are usually always true, so you never hit the false branch.
Thus, branch coverage in Cobertura is messed up by using
assert, since assert lines will have 50% branch coverage, rendering the overall branch coverage percentage hard to interpret (or useless).Clover has a nice feature to ignore
assertwhen computing coverage. I haven't seen this feature in any open source Java coverage tool.If you use assertions in a design-by-contract style, there is no need to add tests that make your Java
assertstatements fail. As a matter of fact,for many assertions (e.g., invariants, post-conditions) you cannot even create objects that would make them fail, so it is impossible to write such tests.
What you can do, though, is use the invariants/postconditions to derive test cases exercising their boundaries -- see Robert Binder's invariant boundaries pattern. But this won't make your assertions fail.
Only if you have a very tricky pre-condition for a given method, you may want to consider writing a test aimed at making the pre-condition fail. But then re-thinking your pre-condition may be a better idea.
有一个功能请求 (1959691) 已记录 Cobertura 以添加忽略断言行的功能；如果您认为这是一个好主意，请随时观看他们的实施情况并在页面上添加评论。遗憾的是，目前还没有一个开源覆盖工具支持这一点，因为我绝对认为断言语句是一个好主意，但测试它们通常是不切实际/不可能的。
There's a feature request (1959691) already logged for Cobertura to add the ability to ignore assert lines; feel free to watch it in case they implement and add a comment to the page if you think it's a good idea. It's a shame none of the opensource coverage tools support this yet, as I definitely think assert statements are a good idea, but testing them usually isn't practical/possible.
代码覆盖率是一个可以让您改进测试的工具，它不是测试有效性的某种证明。通过以 100% 的代码覆盖率为目标、查看未覆盖的内容并反思如何改进测试，您可以从中获得价值。
发现存在未覆盖的断言语句只是一个示例，您应该调用：“好吧，无需覆盖此”。一个类似的例子是跟踪宏和调试代码，它们添加了从未被覆盖的隐藏“if 语句”。
我想您不喜欢您的答案的是您希望对代码有最低的代码覆盖率要求；我的一些项目也遇到了同样的问题。如果必须不丢失覆盖率数据，一种解决方案是进行“覆盖率构建”，其中有问题的语句（断言、跟踪等）被替换为空语句（例如通过宏或链接器魔术） 。但我相信，接受不完美的覆盖范围通常是更好的权衡。
祝你好运。
Code coverage is a tool which allow you to improve your testing, it is not a some kind of proof for the validity of your tests. You get the value from it by aiming to having 100% code coverage, looking at what is not covered, and reflecting on how to improve your tests.
Finding that there are uncovered assert statements is just an example where you should call: "ok, no need to cover this". A similar examples for this is with tracing macros and debug code which adds hidden "if statements" which are never covered.
I guess what what you don't like about your answer is that you like to have a minimal code-coverage requirement for your code; I faced the same issue with some of my projects. If one must not lose the coverage data, one solution is to have "coverage build" where the problematic statements (assert, trace, etc.) are replaced with empty ones (say through macro or linker magic). But I believe this it is usually a better trade-off just to accept the non-perfect coverage.
Good luck.
据推测，您正在使用断言来验证先决条件或其他一些条件集。考虑您的情况是否类似于参数异常应该进行单元测试。
无论如何，我希望您最终会尝试确定是否应该测试这些语句的负路径分支。
是的，无论如何，测试一下这些。你的断言本身就是关于你的假设的逻辑，测试你的防护语句是否能防止/保护你认为它们会发生的情况是一件好事。
Presumably you're using assertions to verify pre-conditions or some other set of conditions. Consider whether your situation is similar to Argument Exceptions should be Unit Tested.
In any case, I expect you're ultimately trying to determine if you should test the negative-path branches of these statements.
Yes, by all means, test those. Your assertions are themselves logic about your assumptions, and it's a Good Thing to test that your guard statements prevent/protect the scenarios you think they do.