neotest(nextest): when running a single test, multiple tests are ran (under some conditions)

[lpiepiora]

Have you read the docs and searched existing issues?

• I have read the README's troubleshooting guide and FAQ(https://github.com/mrcjkb/rustaceanvim?tab=readme-ov-file#left_speech_bubble-faq).
• I am using the latest rustaceanvim release.
• I have searched existing issues.
• I have searched existing discussions.
• I have searched the existing issues of other plugins related to this issue (if applicable).
• I have searched the existing rust-analyzer issues (if applicable).
• I can reproduce the issue with stable Neovim (not a distribution or nightly) and the minimal config.
• This is an issue about rustaceanvim, not rust-analyzer or Neovim.
• This is not an issue with autocompletion.

Neovim version (nvim -v)

v0.10.2

Operating system/version

MacOS

Output of :checkhealth rustaceanvim

==============================================================================
rustaceanvim: require("rustaceanvim.health").check()

Checking for Lua dependencies ~
- WARNING dap not installed. Needed for debugging features [mfussenegger/nvim-dap](https://github.com/mfussenegger/nvim-dap)

Checking external dependencies ~
- OK rust-analyzer: found rust-analyzer 0.3.2220-standalone (27e824fad4 2024-12-15)
- OK Cargo: found cargo 1.83.0 (5ffbef321 2024-10-29)
- OK rustc: found rustc 1.83.0 (90b35a623 2024-11-26)
- OK debug adapter: found codelldb 

Checking config ~
- OK No errors found in config.

Checking for conflicting plugins ~
- OK No conflicting plugins detected.

Checking for tree-sitter parser ~
- WARNING No tree-sitter parser for Rust detected. Required by 'Rustc unpretty' command.
- OK .vscode/settings.json loaded without errors.

How to reproduce the issue

This issue happens when the tests are sharing the same prefix. For example, when tere are tests like this:


#[cfg(test)]
mod test {

    #[test]
    fn test_function_1() {
        let x = 100 * 2;
        assert_eq!(x, 200);
    }

    #[test]
    fn test_function_1special() {
        let x = 100 * 3;
        assert_eq!(x, 300);
    }

}

Expected behaviour

Only the tests that is selected for execution runs.

This problem is caused by the fact, that there is an --exact flag being removed from the nextest runner, as it used to not be supported. There are couple of ways this can be fixed. The flag is now supported, since version 0.9.81: https://nexte.st/docs/running/#--skip-and---exact

Another way would be to run it with the previously supported way, so that instead of the

$ cargo nextest run --package rust-test --bin rust-test -- test::test_function_1
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.01s
------------
 Nextest run ID aa49bb32-7041-4924-b9c3-ce04e3ab2832 with nextest profile: default
    Starting 2 tests across 1 binary
        PASS [   0.023s] rust-test::bin/rust-test test::test_function_1
        PASS [   0.022s] rust-test::bin/rust-test test::test_function_1special
------------
     Summary [   0.025s] 2 tests run: 2 passed, 0 skipped  

one can generate the following command:

$ cargo nextest run --package rust-test --bin rust-test -E 'test(=test::test_function_1)'
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.00s
------------
 Nextest run ID 7744508f-16b1-48d4-9c53-483d9d73b4c8 with nextest profile: default
    Starting 1 test across 1 binary (1 test skipped)
        PASS [   0.018s] rust-test::bin/rust-test test::test_function_1
------------
     Summary [   0.019s] 1 test run: 1 passed, 1 skipped

Actual behaviour

Running the first test will run both (You can see that in the output), which is confusing. The reporter will report it correctly, but when inspecting output one can see that both tests ran:

    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.24s                                              
------------
 Nextest run ID 7cd58568-a4e3-4a2c-9df1-71a57ada2bca with nextest profile: default
    Starting 2 tests across 1 binary
        PASS [   0.018s] rust-test::bin/rust-test test::test_function_1
        PASS [   0.017s] rust-test::bin/rust-test test::test_function_1special
------------
     Summary [   0.019s] 2 tests run: 2 passed, 0 skipped

The minimal config used to reproduce this issue.

1. Create a project with `cargo new`
2. Paste this in the `main.rs`



fn main() {
    println!("Hello, world!");
}

#[cfg(test)]
mod test {

    #[test]
    fn test_function_1() {
        let x = 100 * 2;
        assert_eq!(x, 200);
    }

    #[test]
    fn test_function_1special() {
        let x = 100 * 3;
        assert_eq!(x, 300);
    }

}

[lpiepiora]

PS. I'm happy to provide a PR with a fix, if given some guidance on the preferred solution, if this is something you're considering to fix

[mrcjkb]

Hey 👋

thanks for reporting 🙏
I think the simplest solution would be not to remove the --exact flag, if it is now supported.
We could report an error in rustaceanvim/health.lua if cargo nextest --version reports an older version than 0.9.81 (see :h vim.version.parse).

PS. I'm happy to provide a PR with a fix, if given some guidance on the preferred solution, if this is something you're considering to fix

It's quite late where I am, so I won't be able to review before tomorrow.
I could probably also look into it myself tomorrow evening 😄

[lpiepiora]

It's quite late where I am

same here 😅 - I was thinking I could produce something tomorrow.

Removing the flag is easy - I did that locally, but I'm not so versatile in Lua / nvim plugin development yet.

I could probably produce something tomorrow midday. Seems like a good issue to start ;)

Edit:

I've quickly glanced over the files you've pointed me to (thx), and it seems that there is an utility external_dependencies, which seems like we could use for that.

I would extend it with the support of checking the version requirements, there is also vim.version.parse(), which seems that could help us easily achieve that.

So basically I'd leave the flag --exact in, and if the enable_nextest is true, then I'll do the check for the external dependency cargo-nextest with that minimal version when doing health check.

I hope this makes sense.

[lpiepiora]

hey, I've created a PR with the change. I've implemented it like we have discussed. I'm not sure if I should also contribute to the CHANGELOG, should I?

[mrcjkb]

Thanks 🙏

No need to update the changelog. That's done automatically by a GitHub actions workflow.