Combine rstest with proptest?

[svenstaro]

Is there any recommended/possible way of using rstest in combination with the amazing proptest? If there were, this would truly make this a killer combination for integration testing.

[la10736]

I'll take a look to it. I'm in the middle of the rush (if we can call rush in a pet project) for the next release but I promise that I'll see what that's mean.

[la10736]

Just to understand. What do you mean is to use rstest in combination withproptest?
If you mean to userstest or rstest_parametrize inside a prpptest macro I don't think it's a simple task because the proptest macro will be processed before and cannot understand rstest syntax. Otherwise, if the question is use both crates in the same test module I don't see any limitation

Can you give me an use case example to work with?

[svenstaro]

For instance, I'd like to use something like

proptest! {
   pub fn fixture() -> u32 { 42 }

    #[rstest]
    fn doesnt_crash(s in "\\PC*", fixture: u32) {
        parse_date(&s);
    }
}

That'd be pretty neat. I'm already using them beside eachother.

[la10736]

Maybe we can try to implement it after proptest-rs/proptest#153 is landed. In this case I can see a [proptest] attribute and desugar my test by take care of proptest syntax.

It will be something like:

pub fn fixture() -> u32 { 42 }

#[rstest]
#[proptest]
fn doesnt_crash(#[proptest::strategy="\\PC*".into()] s: &str, fixture: u32) {
    parse_date(&s);
}

or something like this

[matthew-russo]

Hey -- made it here from the proptest issue. We have an issue over there for adding a way to add explicit cases to proptest:

proptest-rs/proptest#284

I had originally suggested using rstest for this but there were some counter arguments. I'm planning on adding some very basic casing functionality in to the attr proc macro once the impl lands. I think it should still be composable like you're mentioning here since you could just transform the cases in to rstest syntax but I'll make sure to get your input once the PR is up

[la10736]

Great!
I'll take a look to it when PR land. I just see some trouble to combine the async proposed syntax to the rstest one.... but it's just a detail.