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 for cargo nextest && Fixed support for deno #3920
base: main
Are you sure you want to change the base?
Conversation
Apologies for the delay, I was on vacation, still catching up. |
That's okay! |
Well its working, actually its my second version working, the fist one used locks. But according to the the library documentation it shouldn't work (at least cross-platform):
Anyway, the overhead was as bad as I expected, as each test execution now requires the same overhead as a complete assembly, I only tested on firefox so far, about 12-13s each, thermal throttled. But when tests take longer than the overhead, the extra cores start to payoff. I'm having thermal throttling issues, but my speed boost might be around 3x when I have the tests configured for very heavy parameters, its a property based testing variation. |
…g error to invocation without_arguments.
… invocation without_arguments.
…ation with_an_empty_assembly.
…warning to invocation with_an_empty_assembly.
…cation with_an_empty_assembly.
…gen-cli because of dependency of wasm-bindgen-test-runner. Updated assembly builder to avoid runner runtime conflicts.
…ly to invocation with_an_assembly empty.
… cargo test command.
…ation with_an_assembly with_one_successful_test.
… back the cargo target directory.
…ructure to allow multiple instances of the runner using the same assembly to make the tests faster.
…caching of assembly building.
…t generate random suffix for assembly directory name.
… without anything to be more consistent.
…Execution to invocation with_an_assembly with_one_successful_test.
…_an_assembly with_one_successful_test.
…ation with_an_assembly with_one_failing_test.
…to invocation with_an_assembly with_one_failing_test.
…ution to invocation with_an_assembly with_one_failing_test.
…invocation with_an_assembly with_one_failing_test.
…ation with_an_assembly_with_one_successful_and_one_failing_test.
…execution with_an_assembly_with_one_successful_and_one_failing_test.
…invocation with_an_assembly with_arguments TESTNAME --nocapture --exact with successful_test_match_1_of_2.
…NAME --nocapture --exact.
…ts of the CLI handling of TESTNAME --nocapture --exact.
…st to the invocation with_an_assembly with_arguments TESTNAME --nocapture --exact with successful_test_match_1_of_2.
…d --exact arguments, although not yet used, but clippy forced it.
…he runner into the runtime.
…t summary to the invocation with_an_assembly with_arguments TESTNAME --no-capture --exact with_successful_test_match_1_of_2.
…bout test 2 to the invocation with_an_assembly with_arguments TESTNAME --no-capture --exact with_successful_test_match_1_of_2.
…an_assembly with_arguments TESTNAME --no-capture --exact with_successful_test_match_2_of_2.
…an_assembly with_arguments TESTNAME --no-capture --exact with_partial_test_match.
…an_assembly with_arguments TESTNAME --no-capture --exact without_test_match.
…est 1 standard output to the invocation with_an_assembly with_arguments TESTNAME --nocapture --exact with_successful_test_match_1_of_2.
…est 1 standard output to the invocation with_an_assembly with_arguments TESTNAME --nocapture --exact with_successful_test_match_2_of_2.
…r concurrency conflict.
…hen running with exact.
…imes node with_one_successful_test.
I was waiting for your review, because as I do more tests, I end up finding more stuff to fix, making the review harder on you. Sorry. I ended up fixing support for deno, not sure why, but it was for sure broken. |
…mes deno with_one_successful_test.
…l tests in ubuntu-latest.
… run in the browser.
This is still work in progress:
https://nexte.st/book/custom-test-harnesses.html
Progress
Updated to use docopt
Updated the macro wasm_bindgen_test
Testing
I wasn't sure what was the best place to put the tests in, because of the custom test runner in the cli crate, so I placed them on main tests folder.
I used a variation of BDD that I use for many years now.
-- Although it seems a bit more verbose, it makes writing tests a lot simpler and faster, anyone can understand them and add new ones.
-- When something breaks its very easy to understand why.
-- Although conter-intuitive, in practice I have found that they are a lot easier to update on refactors.
Overhead
Architecture:
-- a folder with the CLI and environment stuff
-- a folder with the wasm handling
-- a folder with the runtimes