-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add PathBuf Arbitrary impl with tests #368
Add PathBuf Arbitrary impl with tests #368
Conversation
Followup to proptest-rs#362. Includes documentation. Thanks to Michael for starting work on this! Co-authored-by: Michael Dougherty <maackle.d@gmail.com>
For me a number of tests failed, I'm not sure why: https://gist.github.com/sunshowers/5ad72397fe70205bbb27cae534d65443#file-gistfile0-txt-L4551-L4685 But those tests also failed for me on main. (This is with |
I have a feeling this isn't quite correct. I think it might generate paths that are too long. Going to try looking at it later this week. |
proptest/src/arbitrary/_std/path.rs
Outdated
|
||
fn arbitrary_with(args: Self::Parameters) -> Self::Strategy { | ||
static_map( | ||
(any::<bool>(), any_with::<Vec<OsString>>(args)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm not familiar with the OsString
arbitrary impl but I'm wondering if it can generate a string with a delimiter in it. will pull this locally and mess around more. otherwise this looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OsString strategy does indeed generate strings with the delimiter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's okay, the number of delimiters is not a hard and fast rule here.
I'm more concerned about the number of components being too large by default.
I'm wondering if we should define a PathParameters struct with a custom default value for the number of delimiters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did notice that quite a few components were getting generated. I think a PathParameters
struct with a default number and ensuring the output has that number (which may involve trimming any excess generated) could make sense. I think it'd be an un-intuitive if a user asks for n
segments and we give them n
+ m
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. You're welcome to work on it, or I'll get around to it at some point later this week (speaking at RustConf in 3 days 😅)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@matthew-russo OK, done. Let me know if this makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry work and personal life have kept me quite busy so I missed your last message. Thanks for getting back to this and congrats on the talk!
cfac129
to
839ba52
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm. thanks for the contribution!
|
||
arbitrary!(StripPrefixError; Path::new("").strip_prefix("a").unwrap_err()); | ||
|
||
/// A private type (not actually pub) representing the output of [`PathParams`] that can't be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
non-blocking: it is actually pub(?) not sure if this just means it isn't intended to be publicly used or if this is residual from previous iterations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant that even though it is pub, it is not exported as an API so that backwards compatibility is maintained. Any suggestions for better phrasing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think its a huge deal either way. I would probably just say something like:
"An opaque type representing the output of ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this all looks good to me 👍
Followup to #362. Includes documentation. I'm pretty new to this and I had to cargo-cult a bit so please point out issues!
Thanks to Michael for starting work on this!