Closed cenfun closed 5 months ago
Canyon主要解决的是UI自动化测试覆盖率收集难的问题,这个V8 coverge应该还是主要用于nodejs的覆盖率收集吧?对于浏览器端虽然支持,但是现代化的前端应用大多经过babel转译过,V8 coverge的源代码覆盖率还原效果应该是差强人意的。 目前canyon是支持istanbul格式覆盖率数据的上报的,对于v8 coverage容我再了解一下 https://github.com/bcoe/c8
不是的。V8覆盖率可以做到和Istanbul一样甚至更好效果。
确实多数编译都是使用babel来做的,本人公司也使用babel以及Istanbul近十年了,但我们用的是上传到自己部署的sonar服务,自带覆盖率报告功能,在线预览效果可以看云版sonar
但是,现在出现了很多新的构建工具,比如基于rust的swc,基于go的esbuild等,基本都不使用babel了,因为babel的编译性能太低,但比如esbuild本身又不会提供Istanbul的支持(作者有相关的回复) 这样就可以使用原生V8接口来收集覆盖率数据,但V8数据需要做一定的转换才能输出报告,所以才开发了上面那个工具
比如一个vite的react项目,开启sourceMap,可以仅凭v8 coverage获取项目的覆盖率项目么?获取到的应该也是粗略的行、语句覆盖情况吧。无法像istanbul一样在转译时插桩跟踪到具体行、分支、语句、函数的覆盖情况,更多情况下要的应该是源码的覆盖率。
不是的。V8覆盖率可以做到和Istanbul一样甚至更好效果。
确实多数编译都是使用babel来做的,本人公司也使用babel以及Istanbul近十年了,但我们用的是上传到自己部署的sonar服务,自带覆盖率报告功能,在线预览效果可以看云版sonar
但是,现在出现了很多新的构建工具,比如基于rust的swc,基于go的esbuild等,基本都不使用babel了,因为babel的编译性能太低,但比如esbuild本身又不会提供Istanbul的支持(作者有相关的回复) 这样就可以使用原生V8接口来收集覆盖率数据,但V8数据需要做一定的转换才能输出报告,所以才开发了上面那个工具
这周我认真了解一下v8 coverage相关,如果说是“标准”的话,肯定是得支持的。
monocart-coverage-reports 这个项目就可以将V8转换成Istanbul的行、分支、语句、函数,同时V8本身是支持Bytes覆盖的,也就是可以精确到字节位置,而Istanbul本身的语句这些,它是无法统计到结束括号这些的,当然Istanbul也有它的优势就是比如Firefox也能支持,建议可以先去研究一下
monocart-coverage-reports 这个项目就可以将V8转换成Istanbul的行、分支、语句、函数,同时V8本身是支持Bytes覆盖的,也就是可以精确到字节位置,而Istanbul本身的语句这些,它是无法统计到结束括号这些的,当然Istanbul也有它的优势就是比如Firefox也能支持,建议可以先去研究一下
今天看了一下,可以通过c8 report --reporter=json将c8原生的覆盖率数据转换成istanbul格式。可以联系你提供一个实际的测试么?
你可以先就用c8的测试做例子,c8的作者本身应该就是V8引擎的覆盖率功能的主要贡献者 c8使用的是v8-to-istanbul这个库将原生V8数据转换成Istanbul的数据格式,然后调用Istanbul的报告接口生成Istanbul的各种报告,虽然有一些小问题数据可能不大准确,但不影响使用
const v8toIstanbul = require('v8-to-istanbul')
// the path to the original source-file is required, as its contents are
// used during the conversion algorithm.
const converter = v8toIstanbul('',undefined,{
source:"function add(a:number,b:number){\n return a+b\n}\n\nconsole.log(add(1,2))"
})
// await converter.load() // this is required due to async file reading.
// provide an array of coverage information in v8 format.
converter.load().then(res=>{
converter.applyCoverage([
{
"functionName": "",
"ranges": [
{
"startOffset": 0,
"endOffset": 520,
"count": 1
}
],
"isBlockCoverage": true
},
// ...
])
// output coverage information in a form that can
// be consumed by Istanbul.
console.info(JSON.stringify(converter.toIstanbul()))
})
确实可以转换,不过需要有源代码,这要求c8覆盖率上报上来以后拉取源代码才能生成istanbul覆盖率数据。不清楚为什么第一个参数必须要是string。实际上直接给sources.source源代码内容就可以。
所以真的需要在服务端支持v8 coverage的上报么?我看playwright也支持本地转换成istanbul再上报。有真实的使用场景么?因为这样转换的成本确实比较大,服务端得存储源文件来结合生成。
它这个库有很多测试框架在用,比如jest,有很多历史原因,参数可能设计得不那么合理 这也是为什么我开发了自己的转换器和工具,因为前期也是使用v8-to-istanbul有很多问题,实在是无法继续了才另辟蹊径
我还不是很了解你的服务器上报需求是什么,但我个人觉得肯定是在客户端也就是测试端完成最终的数据转换比较好,服务器只需支持最简单的数据格式即可
如果你有机会可以试试monocart-coverage-reports 我都写了中文文档在里面了,应该比较容易了解,测试时收集覆盖率,并生成报告,支持所有Istanbul的报告以及v8的报告,还能自定义报告,最后测试完,在cicd脚本上传到服务器即可,这应该和sonar,codecov这些是类似的
它这个库有很多测试框架在用,比如jest,有很多历史原因,参数可能设计得不那么合理 这也是为什么我开发了自己的转换器和工具,因为前期也是使用v8-to-istanbul有很多问题,实在是无法继续了才另辟蹊径
我还不是很了解你的服务器上报需求是什么,但我个人觉得肯定是在客户端也就是测试端完成最终的数据转换比较好,服务器只需支持最简单的数据格式即可
你的第一条评论说的支持c8覆盖率数据上报。
我说的是上报 V8的覆盖率报告,html格式的,也是一些网页和js文件,预览可以看这里
当然如果是服务端重新根据数据然后生成报告页面,也是可以的,看需要支持什么格式,比如lcov.info
我说的是上报 V8的覆盖率报告,html格式的,也是一些网页和js文件,预览可以看这里
当然如果是服务端重新根据数据然后生成报告页面,也是可以的,看需要支持什么格式,比如lcov.info
那其实canyon已经支持了,因为canyon接受的就是Istanbul的coverage.json类型的数据
明白,当然在客户端转换到Istanbul肯定是没问题的,不过如果后端也能支持原生V8那肯定也挺好,或者更好的支持V8数据, 那这个issue就先关闭了,有其他的问题再另外讨论
Hi, 无意中看到这个项目,看起来好像是一个类似于codecov的项目但可以自己部署。 不过好像只支持Istanbul的覆盖率数据,所以提议,是否可以支持原生的V8覆盖率数据?
关于原生V8覆盖率可以看这里,因为它是V8引擎原生支持,所以性能卓越,也无需编译Istanbul的计数器(Instrumenting source code),意味着根本不需要babel,vite,swc的各种插件(这些插件存在一些兼容问题,导致无法merge)
目前nodejs和主流浏览器都是V8引擎,也就是覆盖了几乎所有JS环境,浏览器前端,node后端,包括单元测试,E2E自动化测试等等,然后V8覆盖率还支持Istanbul不支持的CSS覆盖率,也应该是将来覆盖率的趋势所在
如果有意提供V8支持,本人也有一些相关经验,详情见项目monocart-coverage-reports