Omit case_n for named cases of parameterized tests

[DanielSWolf]

Consider the following parameterized test for a trivial function square:

fn square(i: i32) -> i32 { i * i }

#[rstest]
#[case::negative_value(-5, 25)]
#[case::zero(0, 0)]
#[case::positive_value(3, 9)]
#[case::large_value(10000, 100000000)]
fn squares_the_value(#[case] value: i32, #[case] expected: i32) {
    assert_eq!(square(value), expected);
}

I've given each test case an expressive name to make the generated test names more helpful. The output is as follows:

test repro::squares_the_value::case_1_negative_value ... ok
test repro::squares_the_value::case_2_zero ... ok
test repro::squares_the_value::case_3_positive_value ... ok
test repro::squares_the_value::case_4_large_value ... ok

The generated test name contains both a numbered case_n and the manual case names. To me, the case_n part doesn't add any benefit. For more complex tests with longer names, I find that it makes the test names harder to read.

Would it make sense to omit case_n from the generated names of parameterized tests if the corresponding case has an explicit name?

[la10736]

It was a design choose: I don't want take care of duplication and I would give the possibility to have same description for more than one tests. There are cases where you would provide some cases for the same semantic cases exactly like when you don't provide a description at all.

Of course I can identify clashes and add a postfix only in these cases. I don't reject it because I would consider better this possibility.

[DanielSWolf]

That sounds good. Let me recap to make sure we're on the same page:

• If a case is unnamed, it gets named case_n, where n is the 1-based index of the case within the list of cases.
• If a case is named but not unique, its name gets suffixed with _m, where m is the 1-based index within the clashing group.

To illustrate:

Test:

#[rstest]
#[case::zero(0, 0)]
#[case::negative_value(-100, 10000)]
#[case::negative_value(-5, 25)]
#[case::negative_value(-1, 1)]
#[case(1, 1)]
#[case(3, 9)]
#[case(10000, 100000000)]
fn squares_the_value(#[case] value: i32, #[case] expected: i32) {
    assert_eq!(square(value), expected);
}

Output:

test squares_the_value::zero ... ok
test squares_the_value::negative_value_1 ... ok
test squares_the_value::negative_value_2 ... ok
test squares_the_value::negative_value_3 ... ok
test squares_the_value::case_5 ... ok
test squares_the_value::case_6 ... ok
test squares_the_value::case_7 ... ok

Correct?

[la10736]

You got it Il lun 14 nov 2022, 07:44 Daniel Wolf ***@***.***> ha scritto:

…

That sounds good. Let me recap to make sure we're on the same page: - If a case is unnamed, it gets named case_n, where n is the 1-based index of the case within the list of cases. - If a case is named but not unique, its name gets suffixed with _m, where m is the 1-based index within the clashing group. To illustrate: *Test:* #[rstest]#[case::zero(0, 0)]#[case::negative_value(-100, 10000)]#[case::negative_value(-5, 25)]#[case::negative_value(-1, 1)]#[case(1, 1)]#[case(3, 9)]#[case(10000, 100000000)]fn squares_the_value(#[case] value: i32, #[case] expected: i32) { assert_eq!(square(value), expected);} *Output:* test squares_the_value::zero ... ok test squares_the_value::negative_value_1 ... ok test squares_the_value::negative_value_2 ... ok test squares_the_value::negative_value_3 ... ok test squares_the_value::case_5 ... ok test squares_the_value::case_6 ... ok test squares_the_value::case_7 ... ok Correct? — Reply to this email directly, view it on GitHub <#167 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5Y34JP6GG273QAJPENVPLWIHNWNANCNFSM6AAAAAAR6JZUZA> . You are receiving this because you commented.Message ID: ***@***.***>

[drdavella]

Would you be willing to consider deriving names for unnamed cases from the given case parameters? It is currently quite difficult to determine which test failed based on case_n alone. I do not have a problem with the case_n prefix, though.

EDIT: I see there is already an issue for this here #160. However, I still think this would be a very useful feature, although I do see the problem with converting the expressions to strings.

[la10736]

I should file another ticket for it.... but I'm not incline to implement this feature... I'm writing it for values but cases are different and rust name are very limited (should be an identity) and we cannot know the expression value at compile time: that means we cannot use values for name but just expressions.... Rust is not neither Python or Java/Kotlin :) Il giorno mer 16 nov 2022 alle ore 18:56 drdavella ***@***.***> ha scritto:

…

Would you be willing to consider deriving names for unnamed cases from the given case parameters? It is currently quite difficult to determine which test failed based on case_n alone. I do not have a problem with the case_n prefix, though. — Reply to this email directly, view it on GitHub <#167 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5Y34LEMAUY2UYJWAVLPN3WIUN53ANCNFSM6AAAAAAR6JZUZA> . You are receiving this because you commented.Message ID: ***@***.***>

[DanielJoyce]

If a case fails, the error message should log the actual content of the failing #[case], or the line number of the #[case] attribute that failed. That would make it easier. First one should be doable. Second one might be harder as the macros in macros probably messes up line numbers from the original source file.