我什么时候应该合并我的 Cobertura ser 文件而不是重复使用并添加到一个文件中?

发布于 2024-12-19 17:12:35 字数 229 浏览 2 评论 0原文

我正在运行多个进程来实现代码覆盖率。例如,单元测试和手动测试等。我想要概述我执行代码的所有方式的覆盖范围。

为什么不每次为 Cobertura 指定相同的 .ser 文件呢? Cobertura 会将新数据添加到 ser 文件中。

另一方面,在什么情况下我应该使用单独的 .ser 文件,然后运行 ​​cobertura-merge 命令?

I am running several processes for code coverage. For example, unit tests and manual tests, etc. I want an overview of coverage for all the ways in which I exercised the code.

Why not just specify the same .ser file for Cobertura each time? Cobertura will add new data to the ser file.

On the other hand, under what circumstances should I use separate .ser files, then run the cobertura-merge command?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

空城缀染半城烟沙 2024-12-26 17:12:35

一个可能的例子是,当您的代码库被分段、独立编译和打包,并且您对每个部分独立运行单元测试时。然后,您可以合并 .ser 文件以获得应用程序的完整图片。

如果您对多个应用程序/二进制文件使用“通用”模块,您还可以更准确地了解每个应用程序的实际覆盖范围,特别是如果这对您很重要的话。

另一种情况是,您在代码库上运行单元测试并收集 .ser 文件,然后您还检测二进制文件并运行自动化测试以及功能(手动)测试,每次收集 .ser 文件。
如果您独立生成报告,则不能只打开电子表格并添加覆盖率数字,因为在所有情况下,许多覆盖路径可能都是相同的。

只有通过合并这些 .ser 文件,您才能准确了解在任何测试场景中执行了哪些路径以及哪些路径未执行。


编辑:我意识到我的答案不完整 - 抱歉。你问

为什么不每次为 Cobertura 指定相同的 .ser 文件呢?
Cobertura 会将新数据添加到 ser 文件中。

不过,我觉得这是个人喜好的问题。首先,为了能够通过连续的测试场景“重用”.ser 文件,您需要某种没有外部依赖项的测试管道。如果你满足了这个条件,那么如果对你来说更实用的话,我不反对这样做。

就我个人而言,我更喜欢将其分解为单独的 .ser 文件,然后再将它们聚合起来。一方面,如果某个步骤失败并且我需要重新运行它,我不必担心。此外,如果您对每个测试步骤的细节感兴趣,您还可以提取报告,但在您的管道场景中则不能。仍然不是很引人注目。

One possible example is when your codebase is fragmented, compiled and packaged independently, and you run your unit-tests on each portion independently. You can then merge your .ser files to have a complete picture for your application.

If you use 'common' modules for multiple applications/binaries, you can also get a more accurate picture of the actual coverage of each application, specifically, if that is important to you.

Another scenario would be a situation where you run unit tests on your codebase and collect a .ser file, then you also instrument your binaries and run automation testing, as well as functional (manual) testing, each time collecting your .ser files.
If you generate the reports independently, you can't just open a spreadsheet and add up the coverage numbers, because it's likely many coverage paths were identical in all scenarios.

Only by merging these .ser files will you get an accurate picture of what paths were executed, and which ones were not exercised in ANY of your testing scenarios.


Edit: I realize I had a partial answer - my apologies. You asked

Why not just specify the same .ser file for Cobertura each time?
Cobertura will add new data to the ser file.

However, I feel it is a matter of personal preferences. First of all, to be able to 'reuse' the .ser file thru the successive testing scenarios, you need some sort of a test pipeline with no external dependencies. If you have that condition met, then I don't have any objections to doing it this way if it's more practical to you.

Personally, I prefer to break it down into individual .ser files and aggregate them later. For one thing, if one step fails and I need to re-run it, I don't have to worry about it. Additionally, if you are ever interested into the specifics of each testing step, you can also pull out the report for it, whereas in your pipeline scenario you can't. Still not very compelling.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文