Support output from libtest-mimic #93
Comments
Yes (the latter), cargo is used for test discovery and execution. Do you have a reference project you can share that reproduces the error? Is there any output in the Test Explorer output window? |
No interesting output (aside from warnings about "example" and "bench" being unsupported types, but those are unrelated): The project where I'm observing this is here: https://github.com/GoogleChromeLabs/wasmbin. Just make sure to |
|
Thanks! The unsupported target type is interesting, will try to take a closer look tomorrow |
|
Ahh so there's no issue here, just that your project only has integration and bench tests which we don't support yet (refs #3 and https://github.com/swellaby/vscode-rust-test-adapter#current-features). There's no tests showing in the explorer because there are no unit tests on the $ cargo test -p wasmbin --lib -- --list
Finished test [unoptimized + debuginfo] target(s) in 0.06s
Running target/debug/deps/wasmbin-63ef3693d14345ac
0 tests, 0 benchmarks$ cargo test -p wasmbin-derive --lib -- --list
Finished test [unoptimized + debuginfo] target(s) in 0.05s
Running target/debug/deps/wasmbin_derive-5ddfaf408a794d84
0 tests, 0 benchmarks$ cargo test --test spec -- --list
Finished test [unoptimized + debuginfo] target(s) in 0.06s
Running target/debug/deps/spec-0e584663778ea164
tests/testsuite/linking.wast:3:2: test
tests/testsuite/linking.wast:9:2: test
tests/testsuite/linking.wast:22:2: test
tests/testsuite/linking.wast:27:2: test
... |
|
Hmm I see. What is the practical difference between unit tests and integration tests for the Test Explorer? Do they have different output in If it's the latter, then it seems almost easy to just remove |
It's about correct test discovery and association, both from an organizational standpoint in the explorer but also importantly to support correctly running a given test case. There's no guarantee that there will never be any overlap between mod/test case names, so for execution we have to provide the additional args that include the target kind and in the case of a bin or test target type the associated name. For example, if you have unit tests under a mod named |
Good point. I thought that at least for regular (not mimicked) tests the generated names include full path, and easy to distinguish between lib and integration, but appears not. I'm guessing same applies to doing I don't suppose there is a nice way to fix this and distinguish all targets, but perhaps parsing stderr might help? I see that the combined stderr+stdlog output looks like this: By parsing the |
|
We already have a straightforward plan to incorporate integration tests (it's not a terribly challenging problem to solve), just haven't gotten around to it yet. |
|
Ah fair enough, I'll shut up with my ideas then :D |
Oh no worries, always appreciated and apologies if I gave that impression! I was just noting that the reason we don't support this yet is because of lack of bandwidth and not due to not having a solution. My limited open source time has been pretty tied up in other projects for a while and this one hasn't seen much love recently 😄 Hoping to get back to it in the coming weeks over the holidays. |
That's okay, I know the feeling. Thanks for taking a look at my issue! |
I'm using
libtest_mimicto autogenerate a set of tests with same supported flags as regularcargo testharness.Unfortunately, it seems that Rust Test Explorer doesn't detect those tests in the project. I'm not sure how it performs test enumeration - does it parse source files looking for
#[test]? does it run something likecargo test -- --list? - but in case it's the latter, it is supported by libtest-mimic too and should, in theory, be possible to incorporate into the Rust Test Explorer.E.g. this is the output I'm seeing when running
cargo test -- --liston my project:The text was updated successfully, but these errors were encountered: