-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support to execute tests in workerd #3891
Comments
Code coverage is being tracked in #2276 and there was already a working implementation in #3782, which basically just needed a rebase. It would be good however if somebody took a look at how to fix
This is the path we want go down. A proposal how this would be tackled and some design work would be whats needed here. I'm happy to discuss and look at any more specific proposals. |
@daxpedda I gave a look to nextest, it's indeed relevant and in end I would like to support it also, but the missing piece seems to be in nextest. I tested it and got the message:
I'm guessing its best to add support for workerd first. But recognising its relevance, I'm taking it in consideration, its documentation says:
With cargo test its up to the binary to run individual tests in parallel, so in that model it would make sense for the test-runner to run tests in parallel launching multiple vms and distributing the load. To support the cargo-nextest model its trickier because a simpler version would imply starting a vm, running a single test and return. Starting a vm about 400 times for a single crate can be a bit expensive I guess. So i'm guessing, that we need to have a server that manages all the executions and gets called by multiple clients, that is able to work in both modes. I'm going to update my roadmap to include nextest and cargo-mutants. |
I'm not following where VMs come into play here. Seeing the error you posted, it seems to me the issue in This is a general issue in Let me know if I missed anything here! |
@daxpedda Well if the problem is with wasm-bindgen-test that isn't providing the proper test list, I can start with that, no problem. I need to learn that part anyway. Regarding the execution, nextest invokes the binary once for each test, that would imply starting the browser / node / workerd, run the test and exit, in a simple direct implementation. |
I think that's a good step forward: aligning the output of
This might be a bit too much overhead for parallelizing tests with In any case, this is something to ponder upon later when we actually have some data. |
Motivation
I'm already developing for the workers-rs platform (workerd)
I need to
I already have some support and I plan to tackle this problems as much as possible, I'm highly motived and self reliant.
But I believe that your guidance is quite important:
Proposed Solution
The expected roadmap should be something like:
Workerd is started and configured by Miniflare, I believe it will be a test runner in JS/TS, that I'm guessing will be opaque like the other testing platforms.
Although some kind of streaming of the output could be nice.
Alternatives
I have discussed some details of the strategy with Miniflare lead dev several times, it seems reasonable and recently I was no longer told to wait, that I could start moving forward.
The integration of the runner with your test runner, would be something nice to have, I don't mind working on a more general solution that also allows other test runners.
Additional Context
Back on #3510
@daxpedda said:
@hamza1311 said:
The text was updated successfully, but these errors were encountered: