Skip to content

Clean up specializations tests #461

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

Merged
merged 9 commits into from
Jul 17, 2020

Conversation

phimuemue
Copy link
Member

In response to this comment #413 (comment):

If the contribution is an optimized specialization of an Iterator method (such as nth or fold), the specialization needs to be very thoroughly tested (preferably with quickcheck tests) to ensure it behaves identically (especially on edge cases, and with when it panics).

I thought about having a simple way to test specializations: If we had one test function testing all specializations, we would have an easy way to quickcheck specializations for our iterators.

We already had quite a bit in place, so I took it and streamlined it a bit.

  • fold is tested by remembering all elements provided to the closure (instead of only XORing elements).
  • cleaned up some things (unused specialization of size_hint, some redundant lifetimes, superfluous arguments)
  • test all specializations in one function (instead of only some specializations in two functions)
  • remove manual special case tests in favor of quickcheck'd ones

If we decide to do it like this, we can, in a future commit, just do the following for all iterators (possibly via a macro) to test specializations uniformly (and hopefully reliably):

quickcheck! {
    fn test_specializations_qc(params_for_iterator) -> () {
        test_specializations(&make_iterator_to_be_tested(params_for_iterator));
    }
}

This way, we would also test methods that are not even specialized, but for simplicity, I'd be willing to accept this. If we see that it slows things down considerably, we could still devise a simple solution that would allow to specify the methods to be tested.

Instead of XORing everything, remember all the intermediate parameters
and simply push elements into a Vec, relaxing the type constraints.
Additionally, specializing something in `Unspecialized` does not seem
reasonable.
It should be enough to test against the unspecialized `count`, so we can
simplify the argument list.
@jswrenn
Copy link
Member

jswrenn commented Jul 17, 2020

This is slick!

bors r+

@bors
Copy link
Contributor

bors bot commented Jul 17, 2020

Build succeeded:

@bors bors bot merged commit 9769e75 into rust-itertools:master Jul 17, 2020
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.

2 participants