Add iterator input functions as arguments

[foresterre]

Overview:

Add an input method based on any function which returns impl IntoIterator<Item=V> where the type of V is of the same type as a function argument.

For example for the following test case, the type of V would be either &str or u32:

#[parameterized(input = { "0", "1", "2" }, expected = { 0, 1, 2 })]
fn my_test(input: &str, expected: u32) {
    let parsed: Result<u32, ()> = input.parse().map_err(|_| ());
    assert_eq!(parsed.unwrap(), expected);
}

(Proposed) Syntax:

#[parameterized(fn my_inputs as input, expected = { 0, 1, 2 })]

or

#[parameterized(using my_inputs as input, expected = { 0, 1, 2 })]
fn my_test(input: &str, expected: u32) {
    let parsed: Result<u32, ()> = input.parse().map_err(|_| ());
    assert_eq!(parsed.unwrap(), expected);
}

fn my_inputs() -> impl IntoIterator<Item = &'static str> {
    vec!["0", "1", "2"]
}

or

#[parameterized(using v = my_provider)]
fn my_test(v: Option<i32>) {}

fn my_provider() -> impl IntoIterator<Option<i32>> {
    vec![Some(1)]
}

Considerations:

• Always at least one finite iterator expected; or a finite expression based input from which we can take the max length as the amount of test cases

• https://doc.rust-lang.org/std/iter/trait.ExactSizeIterator.html

[Tockra]

Is here something planned?
I've a list of always the same application endpoints in my tests and currently I have to add this big list again and again to every test instead of defining a global iterator and providing it to all tests (and defining it in a single place)...

[foresterre]

I didn't implement this yet, mostly because I didn't need it thus far. I'm happy to add it though! Feel free to send a PR if you want (I can implement it myself too, but cannot promise a timeline because of other responsibilities).

What kind of syntax would you like to see?

[Tockra]

What kind of syntax would you like to see?

I don’t have a strong preference regarding the syntax. My main concern is having a way to define a static list once and reuse it across multiple tests.

At the moment, this feature request isn't high enough on my priority list to dive into Rust macros. I have no prior experience writing macros, and it would likely take me several hours just to get to a point where I could make meaningful changes.

That said, I believe having a mechanism to avoid duplicating the list of endpoints in this test setup would benefit everyone working on similar tasks. Keeping things DRY (Don't Repeat Yourself) would improve maintainability and reduce potential errors.

Here’s an example of the current situation:

[foresterre]

Thanks for the example! that helps a lot!