A way to test WASM aims to be run in the web worker
Opened this issue · 10 comments
Feature request for a way to test WASM go app that aims to run inside a web worker.
Would there be any difference in terms of test coverage? Can you mention a concrete example where this might be helpful? Thanks.
Currently, the test binary being run is directly instantiated as a WASM and run in the main thread. Whilst, if I have a Go WASM aims to be run in the web worker, it will need to be launched a parent script (e.g.) running in the main thread. It would be helpful if there can provide a way to allow users to specify the test binary should be run as a web worker, and the http server bootstrap the worker for the users.
But what difference does it make in terms of test coverage? Are you trying to test the web worker or the test code? Regardless of whether the test code runs in the main thread or the web worker, it does the same thing. Unless you are specifically testing postMessage / onMessage functionality in a wasm app, in which case you would also need control over the main thread + web worker.
That said, I only care about the test coverage of the Go code that is running inside the web worker. Is there an example showing how I can achieve that by using the wasmbrowsertest?
It does not make any difference to the test coverage. It's still the same browser and the same wasm implementation. You should be able to confidently use your actual code in a web worker, without having to run the test code in a web worker as well. I would be curious to know if there are any actual differences.
I realized the main ask is to have a test framework for the integration test between the main thread and the web worker, which seems to beyond the scope of this tool?
Aha, yes thanks for the clarification. So just to confirm: are you loading a wasm file from your worker? Or are you also communicating with worker/main thread from inside the wasm file? As in - making postMessage / onMessage calls from Go.
Yes, I'm loading a wasm file from within the worker, and then it will communicate with the outside via postMessage and onMessage calls, from Go. The outside is also a Go wasm btw.
Right. This is what I asked for in my second message:
Unless you are specifically testing postMessage / onMessage functionality in a wasm app, in which case you would also need control over the main thread + web worker.
This isn't beyond the scope I'd say, but stretching the original vision slightly. The challenge here would be to run both webworker and non-webworker tests together, as they require fundamentally different approaches. Because a user can do go test . in a directory containing different types of tests and it would require setting up a web server differently for webworker tests and non-webworker tests.
I'd be happy to take a look at a design proposal if you want to work on it. Thanks.
Indeed! The typical test flow of Go is like it compile one test binary and run it (no matter how many test case it includes). Whilst, in this scenario we would need at least two test binaries: non-webworker one and webworker one. Furthermore, both of them should be able to assert and fail the test. So that is why I think it is beyond the scope of the Go test framework, but fit another test flow, probably still based on this project.