Skip to content
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

Optionally implement Arbitrary for Naive{Date,Time,DateTime} #559

Closed
wants to merge 2 commits into from

Conversation

asayers
Copy link
Contributor

@asayers asayers commented May 4, 2021

I'm not sure if you guys are interested in taking a change like this. If you are, I'd be happy to fill in more impls.

@quodlibetor
Copy link
Contributor

It seems like arbitrary is intended for use by fuzzers, are there examples of its use elsewhere? I don't have a lot of context from this PR.

@greyblake
Copy link
Contributor

@quodlibetor I'd love to use it.
It's not only for crazy fuzzers but also for something what is rather a property based testing.
E.g. particulary in my case: I have number of relative big domain models, which then transformed into DB records.
I have also transformer functions that works in the opposite direction.
Currently if I want to unit test it, the amount of tests I have to write is proportional to the complexity of the structures I have.
I could use Arbitrary it would be just a couple lines of code:

  • Generate a random domain model
  • Transform it to DB records
  • Transform DB records back
  • Compare the original model with that one we got

This test would be much more smaller and, what is also important, not biased (unlike me, a developer).

@djc
Copy link
Contributor

djc commented Aug 13, 2022

If someone is willing to rebase or resubmit it, I would certainly consider it worthwhile.

@greyblake
Copy link
Contributor

@djc Hi! The PR was rebased (unfortunately I also missed that).
Would you consider merging the PR or is there something else is required to get it merged?

#[cfg(feature = "arbitrary")]
impl arbitrary::Arbitrary<'_> for NaiveTime {
fn arbitrary(u: &mut arbitrary::Unstructured) -> arbitrary::Result<NaiveTime> {
let secs = u.int_in_range(0..=86_400)?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly these ranges should not be inclusive... a day has up to 86399 seconds, and frac is supposed to be smaller than 2_000_000_000.

See

if hour >= 24 || min >= 60 || sec >= 60 || nano >= 2_000_000_000 {
.

impl arbitrary::Arbitrary<'_> for NaiveDate {
fn arbitrary(u: &mut arbitrary::Unstructured) -> arbitrary::Result<NaiveDate> {
let year = u.int_in_range(MIN_YEAR..=MAX_YEAR)?;
let ord = u.int_in_range(1..=366)?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we construct the YearFlags and determine the exact ndays in the year so constructing the date wouldn't fail

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't seem like it makes a particularly large difference?

fn arbitrary(u: &mut arbitrary::Unstructured) -> arbitrary::Result<NaiveTime> {
let secs = u.int_in_range(0..=86_400)?;
let frac = u.int_in_range(0..=2_000_000_000)?;
Ok(NaiveTime { secs, frac })
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like something that might be better to use from_num_seconds_from_midnight_opt (and unwrap it with a clear error that it is a chrono bug if it fails). That way you can't silently make invalid NaiveTimes.

And yeah, a secs of 86_400 will be rejected.

@greyblake
Copy link
Contributor

@asayers @djc @conradludgate

I am very interested in this support of Arbitrary. Since @asayers apparently has no time to address the code review, I've done it on my own and opened a new PR: #848 (which is alternative to this one)

@greyblake greyblake mentioned this pull request Oct 17, 2022
@greyblake
Copy link
Contributor

@djc This one can be closed, since #849 was merged.

@djc djc closed this Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants