Tag: code coverage

Jmockit没有合并使用coverage-output = serial生成的两个coverage.ser文件

我有一个maven项目我使用参数-Dcoverage-output=serial运行junit。 每次运行后，我在相同父文件夹下的diffeerent文件夹中备份每个coverage.ser文件，然后运行ant任务生成覆盖率报告。 喜欢这个 JMockit正在生成覆盖率报告和index.html，但没有合并两个报告。 它似乎只使用第一个生成报告（哪个文件夹是ant构建文件中的参数中的第一个） coverage.ser 。

为什么Cobertura在运行Eclipse插件时会报告0％的覆盖率？

（这些问题有很多，但是我能找到的所有问题都与Maven有关。在你提出这个问题之前，请注意这一点是重复的，请理解这与Maven没有任何关系。） 我在Eclipse中使用Cobertura来确定我的JUnit测试所涵盖的代码百分比。 我所有的99个unit testing都在Cobertura内外成功运行，但Cobertura报告说他们已经覆盖了我的代码的0％。 一世 ： 我正在通过Eclipse插件运行Cobertura 我在Ubuntu上使用Java 6，特别是OpenJDK-AMD64 确保unit testing确实覆盖了我的代码的某些部分 确保Cobertura在我的所有src文件夹上运行我的所有测试文件夹 试图清理和重建 为什么Cobertura报告0％？

如何添加注释以从jacoco代码覆盖率报告中排除方法？

我有一些Java代码，我想从代码覆盖中排除。 我该怎么办？ 我希望能够添加注释。 有没有办法配置或扩展jacoco（在gradle中使用）来使用它？ 例： public class Something { @ExcludeFromCodeCoverage public void someMethod() {} }

jacoco分支覆盖范围和Sonar条件覆盖范围有什么区别？

我正在尝试使用SonarQube扫描仪（版本3.1.0.1141）分析Java代码。 SonarQube版本：5.6.6 Sonar Java插件版本：4.12.0.11033 jacoco版本：0.8.0 我已经使用这些属性填充了sonar-project.properties： # Sonar sources and metadata sonar.language=java sonar.sources=src/main sonar.java.source=1.8 sonar.sourceEncoding=UTF-8 sonar.java.binaries=target/classes sonar.java.libraries=target/lib sonar.tests=src/test sonar.java.coveragePlugin=jacoco sonar.junit.reportsPath=target/surefire-reports sonar.surefire.reportsPath=target/surefire-reports 虽然jacoco报告给了我一个类的结果： 覆盖率： 84％ 分行覆盖率： 71％ 错过： 9 复杂性： 24 错过： 6 台词： 69 错过： 0 方法： 8 错过： 0 课程： 1 SonarQube显示措施： 条件覆盖率62,5％ 覆盖率81,7％ 线路覆盖率92,8％ 线路覆盖69 总体条件覆盖率62,5％ 总体覆盖率81,7％ 总体线路覆盖率92,8％ 整体未覆盖的分支15 整体未覆盖的线条5 未覆盖的分支15 裸露的线条5 根据声纳度量定义页面 […]

为什么艾玛没有全面报道最后一块？

我不明白为什么艾玛没有给“最后”块提供完整的代码覆盖。 我做了一个简短的示例程序来演示这个。 当我执行程序时，它显示： try finally 所以我不明白为什么最终被标记为红色（未执行）并且“finally”“println”被标记为黄色（部分执行）。 我错过了什么吗？ 如何让emma了解finally块被覆盖？ 谢谢！

如何计算关于Web应用程序代码的selenium测试的代码覆盖率

我要求将我的selenium测试的代码覆盖率捕获到所涵盖的服务器代码（Web应用程序源代码）中的源代码量。 例如，登录function的测试应捕获Web应用程序中为登录function所涵盖的代码量。 否则，需要知道它已经在Web应用程序代码中触及了哪个包或类，以用于完成的方案。 例如登录 我找不到合适的解决方案，虽然我开始了解Jacoco代码覆盖工具，并尝试使用Jacoco Jenkins插件的一些示例，但没有成功。 我不知道可能性。 请提供给我一个如何实现这一点的建议，在此先感谢

Jacoco eclipse插件和SonarQube中的代码覆盖率百分比值不同

我有一个Java项目。 根据Jacoco eclipse插件（EclEmma Java Code Coverage 2.3.1.201405111647），该项目的代码覆盖率为22.3％。 我生成.exec报告并将其提供给SonarQube并使用声纳跑步者进行分析。 SonarQube的Web界面上显示的代码覆盖率为20.2％。 包级别的覆盖值也与Jacoco的eclipse插件所显示的不同。 怎么可能？ SonarQube不是从Jacoco生成的.exec报告中获取值吗？

Gradle和JaCoCo：来自单独子项目的仪器类

我有一个遗留应用程序，它有一个与应用程序模块分开的unit testing模块。 我正在将项目转换为使用Gradle，结构如下所示： /root /module1 /module2 … /moduleN /test 其中测试模块执行module1到moduleN的测试（并依赖于它们）。 我知道这不是一个很好的做法，因为它有点挫败了unit testing的目的，但众所周知，遗留代码总是令人头疼。 所以在我开始重构代码之前，每个模块都有自己的unit testing（这意味着以合理的方式拆卸测试模块，即大量工作）我想找到一个临时解决方案来获得正确的代码覆盖率，即，让JaCoCo设备来自module1，…，moduleN的所有类，而不仅仅是模块测试。 有没有办法告诉JaCoCo从其他模块中检测类？

确定哪些测试用例涵盖了一个方法

我正在处理的当前项目要求我编写一个工具，在Web应用程序上运行function测试，并输出方法覆盖数据，记录哪个测试用例遍历哪个方法。 详细信息：正在测试的Web应用程序将是在servlet容器（例如Tomcat）中运行的Java EE应用程序。 function测试将使用JUnit在Selenium中编写。 一些方法将被注释，以便在部署到测试环境之前对它们进行检测。 执行Selenium测试后，将记录带注释的方法的执行。 问题 ：该项目的一大障碍是找到一种方法将测试用例的执行与方法的遍历联系起来，尤其是测试和应用程序在不同的JVM上运行，并且无法传输测试的名称在应用程序中使用情况，并且无法使用线程信息将测试与代码执行相关联。 提出的解决方案：我的解决方案将包括使用执行时间：我扩展JUnit框架以记录测试用例执行的时间，并且我检测应用程序以便节省遍历方法的时间。 我尝试使用相关性将测试用例与方法覆盖率联系起来。 预期的问题：此解决方案假定测试用例按顺序执行，测试用例在下一个测试用例开始之前结束。 这个假设对JUnit来说是否合理？ 问题：简单地说，我是否可以对建议的解决方案进行输入，或者就如何改进并使其在大多数Java EE应用程序上更强大和更具function提出建议？ 或者导致已经实施的解决方案？ 谢谢 编辑 ：要添加更多要求，该工具应该能够在任何Java EE应用程序上运行，并且需要在应用程序中进行最少量的配置或更改。 虽然我知道这不是一个现实的要求，但该工具至少不需要对应用程序本身进行任何大的修改，例如添加类或代码行。

Gradle jacoco覆盖报告有多个子模块？

有没有人知道如何为包含多个gradle子模块的codecoverage的java jacoco报告配置gradle文件？ 我目前的方法只显示当前子模块的代码覆盖，但不显示兄弟 – 子模块的代码覆盖。 我有这个项目结构 – build.gradle (1) – corelib/ – build.gradle (2) – src/main/java/package/Core.java – extlib/ – build.gradle (3) – src/main/java/package/Ext.java – src/test/java/package/Integrationtest.java 当我执行gradlew :extlib:check :extlib:jacocoTestReport执行junit-test“Integrationtest.java”并生成一个codecoverage报告，该报告不包含像Core.java这样的corelib类的codecoverage 结果应该包括Ext.java和Core.java的代码库 我已经读过了 https://docs.gradle.org/current/userguide/jacoco_plugin.html 并使用Gradle过滤JaCoCo报告 但没有发现任何线索 这是gradle文件的内容 // root build.gradle (1) // Top-level build file where you can add configuration options // common to all sub-projects/modules. buildscript { […]