[Proposal] Capture coverage information in wasm-pack test

[aDogCalledSpot]

This follows up on my work in: #2276

I have a very rough proof of concept and would like to discuss further implementation details before moving towards a PR.

The rough idea

• The usual profiler_builtins aren't implemented for wasm, so we need to use minicov
• We want to issue a call to minicov::capture_coverage after the run of every test
  • The data can be dumped across as many files as we like, so we can either dump into a file after every single test, or dump it all at after all tests have run - which would offer more performance
• Afterwards the generated .profraw files can be merged into a .profdata
• A .profdata can be used to generate an HTML coverage report

Building the code

If minicov is linked, then RUSTFLAGS="-Cinstrument-coverage -Zno-profiler-runtime --emit=llvm-ir" wasm-pack test is sufficient for getting the standard compiled wasm from the called cargo build.

However, wasm-interpreter then runs over the file and tries to fetch all the wbgt_describes. Profiling information is already included in these. I made some attempts at using #[coverage(off)] to avoid the generation of calls to the profiler in these functions but was unsuccessful. We can retry this approach if we have the rest working until then I propose the following workaround:

The workaround

All fields related to profiling use i64. Since the interpreter disallows anything other than i32, we can ignore the i64s if we want to capture coverage (add some flag). Otherwise panic as usual.

This means we add the workaround for the instructions i64 const, i64 store, i64 load and i64 add.

Generating the profraw

Using minicov::capture_coverage works fine for getting the data for a single test. Printing the data to a file however doesn't work from a browser. Since the browser already connects to a small rouille server, I suggest creating two extra endpoints in that server:

• /__coverage/append
  • expects the Vec<u8> generated by minicov in the request body
  • appends it to a vec coverage
  • should be called after every test
  • This just moves around an unecessarily large amount of data. We can simply dump once after all tests have run
• /__coverage/dump
  • expects the Vec<u8> generated by minicov in the request body
  • simply dumps the coverage to a file
  • should be called after all tests have run so we only generate a single profraw

The code is pretty straightforward here.

Merging the profraws and generating the HTML

I personally don't think we should be taking care of this. That way it should be possible to merge the coverage of normal #[test] unit tests as well, so that #[wasm_bindgen_test] only needs to be used for code that runs only on wasm. I haven't been able to confirm this yet but I'll be looking into it.

Open questions

Reporting the coverage to the server

The following code works:

wasm_bindgen_test::wasm_bindgen_test_configure!(run_in_browser);

pub fn print_bool(b: bool) -> &'static str {
    if b {
        "It's true"
    } else {
        "It's false"
    }
}

#[cfg(test)]
mod test {
    use super::*;

    #[wasm_bindgen_test::wasm_bindgen_test]
    async fn test_foo() {
        // assert_eq!(print_bool(true), "It's true");
        assert_eq!(print_bool(false), "It's false");
        let mut coverage = Vec::new();
        unsafe {
            minicov::capture_coverage(&mut coverage).unwrap();
        }
        let client = reqwest::Client::new();
        client
            .post("http://127.0.0.1:8000/__coverage/append")
            .body(coverage)
            .send()
            .await
            .expect("Error in append");

        // This shouldn't be done here but in the generated JS code of the test runner
        // after all tests have run
        client
            .post("http://127.0.0.1:8000/__coverage/dump")
            .send()
            .await
            .expect("Failed dump");
    }
}

Ideally, everything from the line with let mut coverage... would be handled automatically. I tried adding all of it to Context::execute but for some reason when I remove the code from the test itself I get the error:

TypeError: The specifier “env” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.

The line causing the issue is immediately the first line of the generated JS file:

import * as __wbg_star0 from 'env';

The final dump can probably just be called with fetch from the test harness once all tests have completed.

Retrieving the server URL

We only know that the port is 8000 when running non-headless. In other cases we need to retrieve it and add it to the code here. This is probably easier if we do all the HTTP requests from the runner itself instead of from expanded tests, since the runner knows the server URL.

Gating coverage execution

Wanting to collect coverage now changes code in following places:

• The interpreter
• The server
• The proc macro
• The test runner

The server doesn't really matter since the endpoints will never be called.

The interpreter will need some sort of flag to inform it that it shouldn't ignore the i64s it comes across. We can probably just add that as a top level CLI argument.

Same as above for the runner.

The proc macro is the most difficult, if we can move all of the responsibility to the runner, then we have nothing to worry about. If some logic dependent on whether we want coverage or not remains in the expanded code then we will probably have to set an environment variable from the CLI tool to generate the correct code which is pretty ugly.

---

You can find my changes to this repo here: https://github.com/aDogCalledSpot/wasm-bindgen/tree/coverage

[aDogCalledSpot]

Pinging @daxpedda

[egasimus]

Yo, exciting stuff! Is this already in a state where I can try it out?

[aDogCalledSpot]

Yo, exciting stuff! Is this already in a state where I can try it out?

Not yet, the questions covered really stop this from being viable until they're resolved. I'll open a PR once it's in a more testable state.

[daxpedda]

All fields related to profiling use i64. Since the interpreter disallows anything other than i32, we can ignore the i64s if we want to capture coverage (add some flag). Otherwise panic as usual.

Would really like to figure out why #[coverage(off)] doesn't work. I don't know enough about this part of wasm-bindgen to say for sure this won't cause problems in the future, but considering this will be an unstable feature it's fine.

Reporting the coverage to the server

The following code works:

As you said: most of this should be moved to the runner. I don't think we need to use an "append" endpoint at all, we can just collect all this data in the runner and when it's done send it to the server.

---

This looks good, I'm unsure how we will exactly expose it. Passing an experimental flag to wasm-bindgen-test-runner is probably what we want here. It would also be good to figure out exactly how and what error message to print when the right RUSTFLAGS were not supplied.

A good entry in the wasm-bindgen book will also be essential.

Thank you for doing this. Looking forward to the PR!

[aDogCalledSpot]

Would really like to figure out why #[coverage(off)] doesn't work. I don't know enough about this part of wasm-bindgen to say for sure this won't cause problems in the future, but considering this will be an unstable feature it's fine.

I'll document what I've tried and what I found (and how I found what I found) thoroughly in a separate issue and link TODOS in the code to the issue so that it can easily be picked up again. The issue could be as simple as that I didn't add the annotation in enough places but it could also be more complicated.

As you said: most of this should be moved to the runner. I don't think we need to use an "append" endpoint at all, we can just collect all this data in the runner and when it's done send it to the server.

Agreed, I've updated the proposal.

---

It's now working in chrome and firefox in both headless and not headless and node. I'm not sure how to invoke Deno as the runner but the code is the same as for node.

Passing an experimental flag to wasm-bindgen-test-runner is probably what we want here

Does --coverage and have it print a warning that this is highly experimental sound okay?

I would suggest an additional --profraw-out so a user can supply a path of where to dump the generated data. Default is just the current working directory and the name is the name of the tempdir.profraw.

Will also add an experimental feature for coverage to wasm-bindgen-test, which you will have to opt into to make the calls to minicov. Then we can also add a check for that in the runner - if the function isn't found then the user didn't opt in on the cargo level.

Correct RUSTFLAGS, opt-in in the CLI and opt-in in the Cargo.toml should be sufficient for confirming that someone wants to try this.

A good entry in the wasm-bindgen book will also be essential.

Definitely. Near impossible to use otherwise 😅

[aDogCalledSpot]

Verifying the RUSTFLAGS on every run seems a bit excessive.If we are already printing a warning about using the coverage feature we could simply print a hint linking to the docs I'm going to add for in case they run into trouble. And the docs can say that if their case isn't covered they should open an issue here.

[daxpedda]

Does --coverage and have it print a warning that this is highly experimental sound okay?

Call it --experimental-coverage, no need to print anything, it should be described in --help anyway.

I would suggest an additional --profraw-out so a user can supply a path of where to dump the generated data.

Sounds good!

Will also add an experimental feature for coverage to wasm-bindgen-test, which you will have to opt into to make the calls to minicov.

The flag has to be added in wasm-bindgen-test-runner, which is the application called when running cargo test (or wasm-pack test for that matter (I assume)). So it would work like cargo test -- --experimental-coverage. I think this is the only place where the user hooks in, or what am I missing?

Verifying the RUSTFLAGS on every run seems a bit excessive.

Not sure what you mean, but I originally meant to make sure that users set the right RUSTFLAGS because otherwise they will get some pretty esoteric error messages I assume. So we could just help out with that. In any case, it's just a bonus.

[aDogCalledSpot]

The flag has to be added in wasm-bindgen-test-runner, which is the application called when running cargo test (or wasm-pack test for that matter (I assume)). So it would work like cargo test -- --experimental-coverage. I think this is the only place where the user hooks in, or what am I missing?

The test runner currently gets all its arguments via environment variables, so I would just follow suit there and add take care of handling the command line args in wasm-pack.

So wasm-pack test --experimental-coverage automatically sets WASM_BINDGEN_TEST_COVERAGE=1 and then wasm-bindgen-test-runner will read that env var again.

I originally meant to make sure that users set the right RUSTFLAGS because otherwise they will get some pretty esoteric error messages I assume

Yeah, you simply wouldn't find any coverage data. I'm personally not a fan of going through all the RUSTFLAGS though. If someone were to not use wasm-pack test and manually cargo build and cargo test then the RUSTFLAGS wouldn't have to be set.

[daxpedda]

The test runner currently gets all its arguments via environment variables, so I would just follow suit there and add take care of handling the command line args in wasm-pack.

The wasm-bindgen-test-runner has to also parse arguments passed to it from cargo test.
Which you can see handled here:

wasm-bindgen/crates/test/src/rt/mod.rs

Lines 295 to 314 in adcf778

	pub fn args(&mut self, args: Vec<JsValue>) {
	// Here we want to reject all flags like `--foo` or `-f` as we don't
	// support anything, and also we only support at most one non-flag
	// argument as a test filter.
	//
	// Everything else is rejected.
	let mut filter = self.state.filter.borrow_mut();
	for arg in args {
	let arg = arg.as_string().unwrap();
	if arg == "--include-ignored" {
	self.state.include_ignored.set(true);
	} else if arg.starts_with('-') {
	panic!("flag {} not supported", arg);
	} else if filter.is_some() {
	panic!("more than one filter argument cannot be passed");
	} else {
	*filter = Some(arg);
	}
	}
	}

And passed from here:

wasm-bindgen/crates/cli/src/bin/wasm-bindgen-test-runner/main.rs

Lines 198 to 215 in adcf778

	let args: Vec<_> = args.collect();
	match test_mode {
	TestMode::Node => node::execute(module, &tmpdir, &args, &tests)?,
	TestMode::Deno => deno::execute(module, &tmpdir, &args, &tests)?,
	TestMode::Browser { no_modules } | TestMode::Worker { no_modules } => {
	let srv = server::spawn(
	&if headless {
	"127.0.0.1:0".parse().unwrap()
	} else if let Ok(address) = std::env::var("WASM_BINDGEN_TEST_ADDRESS") {
	address.parse().unwrap()
	} else {
	"127.0.0.1:8000".parse().unwrap()
	},
	headless,
	module,
	&tmpdir,
	&args,

So cargo test -- --experimental-coverage should show up there. I know very little of wasm-pack, but I would assume wasm-pack test -- --experimental-coverage should be passed along correctly as well?

In any case, now that I think about it maybe we should use an environmental variable anyway and stick with only supporting the same args as the native Cargo test runner.

Ideally in the future, we would figure out a way if coverage is enabled or not without any environment variable or flag at all. Not sure if there is currently a way to do this at all.

Apologies btw, I don't have anything to do with wasm-pack so I'm only talking from wasm-bindgens perspective here!

I originally meant to make sure that users set the right RUSTFLAGS because otherwise they will get some pretty esoteric error messages I assume

Yeah, you simply wouldn't find any coverage data. I'm personally not a fan of going through all the RUSTFLAGS though. If someone were to not use wasm-pack test and manually cargo build and cargo test then the RUSTFLAGS wouldn't have to be set.

I think I have expressed myself very poorly here. What I meant to say is that we should check what happens if users enable coverage but don't pass the right RUSTFLAGS. If this causes really esoteric error messages that are impossible to debug, it would be nice if we could somehow detect that and tell the user whats wrong.

How we would do that I have no clue, so if you have any ideas it would be nice to discuss that.

If all that happens is that there is no coverage data, then that's ideal, no need to do anything here!

But again: this is probably something we can leave for a follow-up.

[aDogCalledSpot]

The wasm-bindgen-test-runner has to also parse arguments passed to it from cargo test.
Which you can see handled here:

The line is commented with

wasm-bindgen/crates/test/src/rt/mod.rs

Lines 293 to 294 in adcf778

	/// Eventually this will be used to support flags, but for now it's just
	/// used to support test filters.

and is followed by

wasm-bindgen/crates/test/src/rt/mod.rs

Lines 296 to 300 in adcf778

	// Here we want to reject all flags like `--foo` or `-f` as we don't
	// support anything, and also we only support at most one non-flag
	// argument as a test filter.
	//
	// Everything else is rejected.

and the test-runner main also says:

wasm-bindgen/crates/cli/src/bin/wasm-bindgen-test-runner/main.rs

Lines 51 to 52 in adcf778

	// Currently no flags are supported, and assume there's only one argument
	// which is the wasm file to test. This'll want to improve over time!

So I think it's best to leave it as an environment variable for now.

Apologies btw, I don't have anything to do with wasm-pack so I'm only talking from wasm-bindgens perspective here!

That's fine. The wasm-pack changes are just parsing a flag. Everything else depends on what happens in wasm-bindgen. Getting the interface correct here is the most important - regardless of wasm-pack.

Ideally in the future, we would figure out a way if coverage is enabled or not without any environment variable or flag at all. Not sure if there is currently a way to do this at all.

Ideally the profiler is built into the .wasm and is supported by LLVM. Then you could just use grcov to take care of everything since executing the file will simply passively generate .profraw files. (Ideally llvm-cov would also be able to parse the DWARF info out of the .wasm since it's actually in there saving us yet another step).

What I meant to say is that we should check what happens if users enable coverage but don't pass the right RUSTFLAGS. If this causes really esoteric error messages that are impossible to debug, it would be nice if we could somehow detect that and tell the user whats wrong.

I understood that. I guess I'm the one who's being cryptic.

Conveniently or infuriatingly, depending on how you want to look at it, you don't really get much output at all when trying to generate coverage data. If you have all the stuff in wasm-bindgen set up correctly but only forget to compile with the correct RUSTFLAGS then minicov won't find any profiling data and won't write anything to the coverage array. This empty array will then be saved as an empty profraw. From there you can actually continue to process this empty file all the way until you have HTML that tells you nothing 😆 I guess we can add a warning if we're dumping an empty file since this is probably not the user's intention.

[daxpedda]

The wasm-bindgen-test-runner has to also parse arguments passed to it from cargo test.
Which you can see handled here:

The line is commented with

wasm-bindgen/crates/test/src/rt/mod.rs

Lines 293 to 294 in adcf778

	/// Eventually this will be used to support flags, but for now it's just
	/// used to support test filters.

These comments are unfortunately outdated, we have since then already started supporting some flags. E.g. --include ignored.

So I think it's best to leave it as an environment variable for now.

Indeed we should still stick with an environment variable here to support the same CLI as the native Cargo test runner. That is until rust-lang/rfcs#3287 is implemented.

From there you can actually continue to process this empty file all the way until you have HTML that tells you nothing 😆 I guess we can add a warning if we're dumping an empty file since this is probably not the user's intention.

I see! Yeah that honestly sounds fine to me, I will leave if you want to add a warning here or not to you.

[aDogCalledSpot]

So there are three things the user has to get right:

• RUSTFLAGS need to be set correctly when building in order to generate profiling information (profiling)
• WASM_BINDGEN_TEST_COVERAGE environment variable needs to be set (flag)
• coverage feature in wasm_bindgen_test needs to enabled (feature)

Here's the output of all the ways you can mix these up:

No profiling, no feature, no flag:
Fine, just as before

No profiling, no feature, flag:
Prints error saying that coverage was supposed to be dumped but feature disabled

No profiling, feature, no flag:
Fine, just as before. Note that you might have issues if you have a crate depending on wasm-bindgen-test that also has minicov as a dependency since you'll have multiple definitions of functions. This is why we have the feature.

No profiling, feature, flag:
Prints error saying that empty coverage data was received. Says what RUSTFLAGS to use (I wanted to have this as a warning but warnings don't seem to be forwarded to the command line in headless mode)

Profiling, no feature, no flag:
wasm-bindgen-interpreter will panic. Prints a hint. (*)

Profiling, no feature, flag:
TypeError: The specifier "env" was a bare specifier
(The JS interpreter can't find the calls to the profiling information)(**)

Profiling, feature, no flag:
wasm-bindgen-interpreter will panic (somewhere else for some reason). Prints a hint.(***)

Profiling, feature, flag:
You get coverage!

(*) If we don't need the workaround in the interpreter, I'm pretty sure this would just take longer to compile but run fine

(**) A better message here would be great but I don't know how to detect this since the problem occurs at link time but it is only printed at runtime.

(***) If we don't need the workaround in the interpreter, this would probably also be fine.

[daxpedda]

Thank you for putting this together!
Hopefully we can figure out a way to address the last three cases somehow in the implementation.

[aDogCalledSpot]

@egasimus PR is open at #3782

[egasimus]

@aDogCalledSpot

Hell yeah, let's go!

I just compiled wasm-pack from your branch with rustc 1.77.0-nightly (30dfb9e04 2024-01-14), and ran:

RUSTFLAGS="-Cinstrument-coverage -Zno-profiler-runtime --emit=llvm-ir" ../wasm-pack-coverage/target/debug/wasm-pack test --chrome --headless --coverage --profraw-out wtest.profraw

Missing feature coverage of course; so I realized I also need to point wasm-bindgen and wasm-bindgen-test in my Cargo.toml to:

[dev-dependencies]
wasm-bindgen-test = { git = "https://github.com/aDogCalledSpot/wasm-bindgen", branch = "coverage", features = [ "coverage" ] }

[dependencies]
wasm-bindgen = { git = "https://github.com/aDogCalledSpot/wasm-bindgen", branch = "coverage" }
# my other deps:
js-sys = "0.3.64"
tinyrand = "0.5.0"
lazy_static = "1.4.0"
derivative = "2.2.0"

I think that's about right? Now running the same command gets me as far as this dependency error:

Error: `cargo metadata` exited with an error:     Updating git repository `https://github.com/aDogCalledSpot/wasm-bindgen`
    Updating crates.io index
error: failed to select a version for `wasm-bindgen-shared`.
    ... required by package `wasm-bindgen-macro-support v0.2.89`
    ... which satisfies dependency `wasm-bindgen-macro-support = "=0.2.89"` (locked to 0.2.89) of package `wasm-bindgen-macro v0.2.89`
    ... which satisfies dependency `wasm-bindgen-macro = "=0.2.89"` (locked to 0.2.89) of package `wasm-bindgen v0.2.89`
    ... which satisfies dependency `wasm-bindgen = "^0.2.37"` (locked to 0.2.89) of package `console_error_panic_hook v0.1.7`
    ... which satisfies dependency `console_error_panic_hook = "^0.1"` (locked to 0.1.7) of package `wasm-bindgen-test v0.3.39 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-test` of package `myapp v0.1.0 (/home/user/Lab/myapp)`
versions that meet the requirements `=0.2.89` (locked to 0.2.89) are: 0.2.89

the package `wasm-bindgen-shared` links to the native library `wasm_bindgen`, but it conflicts with a previous package which links to `wasm_bindgen` as well:
package `wasm-bindgen-shared v0.2.89 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-shared` of package `wasm-bindgen-macro-support v0.2.89 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-macro-support` of package `wasm-bindgen-macro v0.2.89 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-macro` of package `wasm-bindgen v0.2.89 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen` of package `js-sys v0.3.66 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `js-sys` of package `wasm-bindgen-futures v0.4.39 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-futures` of package `wasm-bindgen-test v0.3.39 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-test` of package `myapp v0.1.0 (/home/user/Lab/myapp)`
Only one package in the dependency graph may specify the same links value. This helps ensure that only one copy of a native library is linked in the final binary. Try to adjust your dependencies so that only one package uses the links ='wasm-bindgen-shared' value. For more information, see https://doc.rust-lang.org/cargo/reference/resolver.html#links.

failed to select a version for `wasm-bindgen-shared` which could resolve this conflict

Caused by: `cargo metadata` exited with an error:     Updating git repository `https://github.com/aDogCalledSpot/wasm-bindgen`
    Updating crates.io index
error: failed to select a version for `wasm-bindgen-shared`.
    ... required by package `wasm-bindgen-macro-support v0.2.89`
    ... which satisfies dependency `wasm-bindgen-macro-support = "=0.2.89"` (locked to 0.2.89) of package `wasm-bindgen-macro v0.2.89`
    ... which satisfies dependency `wasm-bindgen-macro = "=0.2.89"` (locked to 0.2.89) of package `wasm-bindgen v0.2.89`
    ... which satisfies dependency `wasm-bindgen = "^0.2.37"` (locked to 0.2.89) of package `console_error_panic_hook v0.1.7`
    ... which satisfies dependency `console_error_panic_hook = "^0.1"` (locked to 0.1.7) of package `wasm-bindgen-test v0.3.39 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-test` of package `myapp v0.1.0 (/home/user/Lab/myapp)`
versions that meet the requirements `=0.2.89` (locked to 0.2.89) are: 0.2.89

the package `wasm-bindgen-shared` links to the native library `wasm_bindgen`, but it conflicts with a previous package which links to `wasm_bindgen` as well:
package `wasm-bindgen-shared v0.2.89 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-shared` of package `wasm-bindgen-macro-support v0.2.89 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-macro-support` of package `wasm-bindgen-macro v0.2.89 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-macro` of package `wasm-bindgen v0.2.89 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen` of package `js-sys v0.3.66 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `js-sys` of package `wasm-bindgen-futures v0.4.39 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-futures` of package `wasm-bindgen-test v0.3.39 (https://github.com/aDogCalledSpot/wasm-bindgen?branch=coverage#c8310511)`
    ... which satisfies git dependency `wasm-bindgen-test` of package `myapp v0.1.0 (/home/user/Lab/myapp)`
Only one package in the dependency graph may specify the same links value. This helps ensure that only one copy of a native library is linked in the final binary. Try to adjust your dependencies so that only one package uses the links ='wasm-bindgen-shared' value. For more information, see https://doc.rust-lang.org/cargo/reference/resolver.html#links.

(Previously, I was also using console_error_panic_hook = "^0.1.7" directly, in order to get nice panic traces in console; it caused the same error about wasm-bindgen-shared. I removed that for now, and got the result above.)

Am I doing something wrong? From the looks of it we also need a fork of console_error_panic_hook that depends on your fork of wasm-bindgen?

[aDogCalledSpot]

Try this:

[dev-dependencies]
wasm-bindgen-test = { version = "0.3", features = ["coverage"] }

[patch.crates-io]
wasm-bindgen-test = { git = "https://github.com/aDogCalledSpot/wasm-bindgen", branch = "coverage" }
wasm-bindgen = { git = "https://github.com/aDogCalledSpot/wasm-bindgen", branch = "coverage" }
wasm-bindgen-shared = { git = "https://github.com/aDogCalledSpot/wasm-bindgen", branch = "coverage" }