【发布时间】:2015-05-02 14:14:34
【问题描述】:
我已将 Karma 配置为报告我的 JavaScript 代码的覆盖率。这是karma.conf.js文件中的部分配置:
coverageReporter: {
reporters: [
{
type: 'html',
dir: 'build/karma/coverage'
},
{
type: 'lcov',
dir: 'build/karma/coverage',
subdir: '.'
},
{
type: 'cobertura',
dir: 'build/karma/coverage'
}
]
},
我的lcov.info 文件格式如下:
TN:
SF:./app/scripts/app.js
FN:16,(anonymous_1)
FN:26,(anonymous_2)
FNF:2
FNH:1
FNDA:1,(anonymous_1)
FNDA:0,(anonymous_2)
DA:2,1
DA:20,1
DA:29,0
DA:34,0
LF:4
LH:2
BRF:0
BRH:0
end_of_record
不幸的是,the Sonarqube JavaScript plugin 只考虑以SF:、DA: 或BRDA: 开头的行(参见LCOVParser)。
因此,LCOV HTML 报告(由伊斯坦布尔制作)在相同数据上为我提供了比 Sonar 更高的代码覆盖率。
有没有办法改变生成的lcov.info 的格式?
如果我查看Istanbul code,我可以想象不同标签的含义:
-
BRF、BRH、BRDA用于分支机构。 -
FN、FNF、FNH、FNDA用于函数。 -
LN、LF、LH用于行。 -
*F是总数,*H是覆盖信息。
Istanbul 和 Sonar 覆盖范围之间的差异似乎是由于后者完全忽略了 Functions 和 Branches 覆盖范围。
有什么办法解决这个问题吗?
【问题讨论】:
-
您是否考虑过使用 karma-sonarqube-unit-reporter:npmjs.com/package/karma-sonarqube-unit-reporter
-
我们也遇到了这个问题,然后放弃了直接运行脚本的 javascript 插件。 github.com/carsdotcom/gulp-sonar 是一个不错的插件,可用于您的 gulpfile。它可能不适用于所有情况,但为我们解决了这个问题。
-
我们遇到了类似的问题,声纳需要一个绝对文件路径来计算覆盖率。我们的解决方法是添加一个修改 lcov.info 的构建任务,以在 SF:lines 上添加绝对路径前缀
-
你成功了吗?我坚持使用无法解析文件路径的 lcov 导入,此处解释为 stackoverflow.com/questions/51878860/…
-
@claya,如果您更新构建任务详细信息会很有帮助。所以我可以按照同样的方法来看看它是否有效。我们正在使用团队城市
标签: javascript sonarqube karma-runner lcov karma-coverage