Support for #[rstest] tests

[la10736]

Hi,
an user of my crate ask a way to debug (but also just run today fails) #[rstest]'s tests la10736/rstest#120 . Today the lens appear correctly but the runner execute something like

cargo test --package <package> --bin <binary> -- <test_path> --exact --nocapture

That's ok if you have just a single test that use only fixtures but in the case you have cases or value list the procedural macro create a module that contains test functions or other modules.

So maybe in this case the best would be identify this as a Test module like it is.

Today rust-analyzer use a simple heuristic to identify test function (last argument path segment contains test word) and this work well to find rstest's ones, but look just hir cannot be useful to find how rstest expand it and crate a test module.

So if you are ok I can create a PR that simply catch rstest in runnable_fn and return a RunnableKind::TestMod instead of a RunnableKind::Test.

I know that a catch of explicit rstest is not the best but I don't have any better idea.

Let me know if you like it and I can send a PR.

[Veykril]

Special casing crates like that isn't really something we want to do I think. The main problem here right now is that we don't currently expand attribute macros yet. Once we do we can handle these better though by looking at the expansion for test attributes potentially. Then we could probably just have the lens execute all the tests that the expansion created instead which should fix this.

At least I believe it should work like this.

[la10736]

Ok, reasonable. If I was the rust-analyzer maintainer maybe I had said the same thing.

As workaround can we make the --exact flag an option via configuration flag?

[la10736]

Ok, we're waiting for #6029. Should be fix almost all.

[Veykril]

Ye, attribute macros should come soon-ish at which point this can be tackled 👍 #8971

[Veykril]

So with attribute expansion we do get correct-ish lenses now, but they aren't too helpful the way they are now imo

Snippet:

#[rstest]
#[case(0, 0)]
#[case(1, 1)]
#[case(2, 1)]
#[case(3, 2)]
#[case(4, 3)]
fn fibonacci_test(#[case] input: u32, #[case] expected: u32) {
    assert_eq!(expected, fibonacci(input))
}

The expansion of that snippet is

#[cfg(test)]fn fibonacci_test(input:u32,expected:u32){
  assert_eq!(expected,fibonacci(input))
}#[cfg(test)]mod fibonacci_test {
  use super:: * ;
  #[test]fn case_1(){
    let input = 0;
    let expected = 0;
    println!("{:-^40}"," TEST START ");
    fibonacci_test(input,expected)
  }#[test]fn case_2(){
    let input = 1;
    let expected = 1;
    println!("{:-^40}"," TEST START ");
    fibonacci_test(input,expected)
  }#[test]fn case_3(){
    let input = 2;
    let expected = 1;
    println!("{:-^40}"," TEST START ");
    fibonacci_test(input,expected)
  }#[test]fn case_4(){
    let input = 3;
    let expected = 2;
    println!("{:-^40}"," TEST START ");
    fibonacci_test(input,expected)
  }#[test]fn case_5(){
    let input = 4;
    let expected = 3;
    println!("{:-^40}"," TEST START ");
    fibonacci_test(input,expected)
  }
}

[Veykril]

So I think we probably wanna show Run case_1, ... instead of the generic Run test when this comes from a macro invocation that yields multiple tests? Also a bit odd that we do not sure a runnable for the module at all.

[Veykril]

Veykril@5602f0e

This is how that would look like

[la10736]

Wow!!! That's really amazing!!!
Thanks a lot!