Open blaind opened 1 year ago
Do you have any suggestions for addressing this? You correctly identified https://github.com/rouge8/neotest-rust/commit/c8894d826a2cb5003cb6bc0a2fa8f7a359899130 as the culprit. Is there a way to make that logic conditional? Or detect the correct package/binary and use that?
@rouge8 I think we should try, restricting the scope always. Some crates compilation to fail when testing so I can't use workspace test.
VScode rust-analyzer plugin does this.
cargo test --package clipper --lib -- tests --nocapture
cargo test --package clipper --lib -- tests::test_punctuation --exact --nocapture
Need to look into neotest context for this, will update later.
@blaind Will this work for you as well?
I believe that doesn’t work for non-default packages in a workspace as described in the commit linked above.
Thank you for the excellent library.
I'm encountering an issue when running individual crate tests in a large codebase, and it's causing significant initial slowness. For instance, when working with the Bevy engine repository (https://github.com/bevyengine/bevy/), running tests only in the
crates/bevy_app
crate necessitates building all the examples, resulting in a target directory size of over 150GB and a substantial time investment. I've managed to improve the situation to some extent by adding anargs = { "--lib" }
flag, but the build process remains quite slow due to the workspace flag.The root cause appears to be related to issue #27 and commit c8894d8.
Here are some statistics below, each run starting with a clean target folder.
Current neotest-rust flags (--workspace): very very slow
Without workspace, with --lib: very fast
No arguments
With --lib and --workspace: somewhat reasonable, but still slow