wasm-bindgen-test should use a custom test framework

[gnzlbg]

We should re-implement wasm-bindgen-test to use a custom_test_framework, that would allow people to keep marking their tests with #[test], but it will require them to #[cfg_attr(target = "wasm32", custom_test_runner(wasm_bindgen_test::runner))] once per crate or something like that. Anyways, that's better than what we have now.

[TitanThinktank]

i recently learnt how to run "hello world" program with Rocket rust server, i have never done any web development, and i have no idea why people do these unnecessary "Test" things in good programs; wasmBindgen is already polluted by needless bloat for NodeJs, please do no create more hurdles for using this tech, may be later when there are better alternatives to WebAssembly , for now let us newbies hang on and survive.

And where is the Forum to ask for help ?

[alexcrichton]

@TitanThinktank I've minimized your comment as being off-topic, you've had many similar comments recently along the same lines which are overly aggressive in one way or another.

@gnzlbg I completely agree we should use this! One requirement though is that the current crate must work on stable, but that doesn't mean we could develop an alternate mode that works on nightly. I see this crate as one of the important use cases to take into account when stabilizing custom test frameworks for sure.

[chinedufn]

@gnzlbg @alexcrichton just to clarify, would this prevent you from having #[test] functions that don't run in wasm in the same crate?

Motivation for asking: I have a crate with some wasm_bindgen_test's that I run in the browser but also plenty of regular tests that I don't want to have run in the browser (I haven't profiled .. but I'm assuming that I'm saving on time but not running them through wasm_bindgen_test.)

I think I'm just trying to visualize this better?

• Would all of your tests run through wasm_bindgen_test?
• Would you be able to only run them in wasm_bindgen_test if you included a certain attribute?
• Am I just completely off?

Thanks!

[alexcrichton]

The end goal I envision is that you use #[test] and it "just works" in the browser or in node, so #[wasm_bindgen_test] would go away entirely. For tests that deal with blocking (aka futures) we may keep the attribute around though.

I would also ideally like the end goal of zero configuration (you just depend on wasm-bindgen-test and that's it), but the current custom test framework design doesn't quite support that.

So to answer your question, wasm_bindgen_test I hope becomes an implementation detail that no one really thinks about, and you'd use standard #[cfg] attributes to keep tests as only-wasm or only-not-wasm.

[gnzlbg]

@chinedufn to make more concrete what @alexcrichton said, if when running cargo test --target=wasm32-unknown-unknown there are some tests that you don't want compiled / run, then you could use #[cfg_attr(not(target_arch = "wasm32"), test)] and similar macros to "disable" them.

[chinedufn]

you'd use standard #[cfg] attributes to keep tests as only-wasm or only-not-wasm.

if when running cargo test --target=wasm32-unknown-unknown there are some tests that you don't want compiled / run,

Perfect, thank you!!

[alexcrichton]

@TitanThinktank I've deleted your last comment as it's definitely off-topic. If you'd like to help contribute to this project please do so less aggressively and stay on-topic and cordial. I'll be forced to exclude you from this project if this behavior continues.

[alexcrichton]

I'm going to go ahead and close this because we're not going to switch to the unstable custom test framework infrastructure, but as soon as it's stable we'll switch over!