Support collecting code coverage
nhooyr opened this issue · 7 comments
This is a very useful tool and I'm using it in https://github.com/nhooyr/websocket
It'd be nice to be able to collect coverage from via the -coverprofile flag to go test.
Right now I get:
$ env GOOS=js GOARCH=wasm go test "-coverprofile=ci/out/coverage.prof" "-coverpkg=./..." ./internal/wsjs
PASS
testing: open /var/folders/zd/5rls6whn363cpxvs_2h4fy6m0000gn/T/go-build284234120/b001/_cover_.out: not implemented on js
Thanks, glad it's useful.
Yeah there's no way to do that via the browser because filesystem APIs don't work. I managed to make the CPU profile work by taking a profile from inside Chrome and converting that to a pprof format. But -coverprofile is very Go specific. I'm afraid you will need to use Node for that.
I suppose this is really a Go issue then. I'd expect it'd use a virtual file system of some sort in the browser so that at the very least you could write a file.
It's not a Go issue. It's a browser issue. You don't have filesystem access from a browser. There is a rudimentary API, but it's broken. That's why we don't have browser based trybots for wasm, only Node based. More info here: golang/go#26051. See my comment here and after.
By virtual file system I mean making the go file system APIs write to local storage. Then once the test is complete you could export the file system from local storage with the chromedp protocol.
I see. That would just allow file writes to happen. Not reads from file system. Certainly a solution, but I would rather wait for something full-fledged and works both ways.
I see. That would just allow file writes to happen. Not reads from file system. Certainly a solution, but I would rather wait for something full-fledged and works both ways.
Since you have to serve the WASM file anyway to the browser, what if we added a few endpoints to the server to perform file system operations and then the os package would just call into that API for whatever it needs to do.
Personally, I don't think the os package should be aware of which environment the wasm module is running. The changes should be handled in wasm_exec.js. In any case, this does not look like something that can be solved just by this tool without changing code in the main codebase. So I am going to close this for now.
However, I have my eyes on golang/go#26051. This tool will definitely support filesystem operations when we have proper support for it in upstream.
Thanks for your thoughts. I will keep them in mind when we have a little more clarity on how the support would look like.