Comments (10)
Would there be any difference in terms of test coverage? Can you mention a concrete example where this might be helpful? Thanks.
from wasmbrowsertest.
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.
from wasmbrowsertest.
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.
from wasmbrowsertest.
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?
from 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.
from wasmbrowsertest.
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?
from wasmbrowsertest.
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.
from wasmbrowsertest.
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.
from wasmbrowsertest.
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.
from wasmbrowsertest.
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.
from wasmbrowsertest.
Related Issues (20)
- "panic: newosproc: not implemented" when executing in travis HOT 1
- `could not dial` errors on the latest Chrome on GitHub Actions HOT 4
- Support -shuffle flag HOT 1
- Accept permission HOT 2
- please enable discussions on this repo HOT 4
- Is there an example dockerfile? HOT 1
- goroutine support HOT 14
- Error: command line too long HOT 6
- cross browser testing HOT 5
- using -- to signify end of options HOT 8
- `total length of command line and environment variables exceeds limit` in GitHub Actions HOT 27
- error generating coverage report HOT 7
- update documentation regarding go 1.20 coverage tools HOT 3
- Is there away to click "OK" on an alert window? HOT 2
- getting a webgl context fails on macOS HOT 8
- Flaky test TestRun/panic_fails in Windows HOT 9
- Tests flake when a callback is called after the test finishes HOT 11
- Failed to run while using Go Toolchain HOT 11
- fail with "panic: unexpected call to os.Exit(0) during test" HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wasmbrowsertest.