rstest_parametrize does not work in src/bin files

[la10736]

rstest_parametrize does not work in src/bin files

[la10736]

Hi,
thank you to report it. Could you please post/link an example?

[la10736]

Maybe I don't understand your testcase... in la10736/rstest_issue2 seams to work as expected.... I missed something?

[russel]

I do not have a trimmed down version to act as a test case – at least not yet, but I can try. The actual problem I have observed is with the tests for me-tv-schedule in the Me TV repository. https://github.com/Me-TV/Me-TV/blob/master/src/bin/me-tv-schedule.rs the #[rstest_parametrize] code compiles (if there is an error, it gets flagged so definitely being compiled) but is not actually run. The #[test] entries above are executed as normal.

I pulled the rs8080 project and ran it's tests and they work fine for me, but they are in src/ not src/bin/. The test cases you mention are all spawning a process to run the tests (I believe) and so are a somewhat different thing to what I have.

I have no idea what might be wrong, which is why it is so vexing.

[la10736]

Hi, maybe I got it. You cannot write arbitrary rust code in code annotation. To work around this limitation I used Unwrap("<some rust code>") syntax. So, try to change your code into:

    #[rstest_parametrize(
        datum, expected,
        case("2018-12-29T18:15:33", Unwrap("NaiveDate::from_ymd(2018, 12, 29).and_hms(18, 15, 33)")),
        case("2018-12-29 18:15:33", Unwrap("NaiveDate::from_ymd(2018, 12, 29).and_hms(18, 15, 33)"))
    )]
    fn parse_datetime_string(datum: &str, expected: NaiveDateTime) {
        match parse_to_datetime(datum) {
            Ok(result) => assert_eq!(result, expected),
            Err(e) => assert!(false,"failed to parse: {}", e),
        };
    }

As value in your test case you can use just direct value as numbers, bools and strings or if you need to write some rust statements use Unwrap("<code>") construct.

I know that Unwrap is not a good name but I didn't found any better one. Maybe I'll use a shorter one in the next version like r("<code>").

[russel]

Aha, that was it. Works now. :-)

It is a shame having to put code as string since it is easy to put syntax errors in that are not checked by IDEs and compiler until test execution time. However, having parameterised tests is a huge saving in lack of boilerplate.

I did contemplate trying the "use a macro" technique of handling the boilerplate, but I really like pytest.mark.parametrize so went with rstest instead! I will be using this a lot, thanks for making it.

[la10736]

Next release will report errors like this and checks the Unwrap strings at compile time with readable errors.
For IDE highlight I hope to have some time to look in intellJ language injection to have it at least in IntelJ.

[russel]

Having syntax checks early will be very helpful.

I use CLion for Rust (because of gdb support) rather than IntelliJ IDEA, but I think there is no difference for plugins. I guess contacting the Rust plugin team at JetBrains is a good first step?