The proptest::arbitrary::Arbitrary trait lets us create values using a generic any free function. It would be really convenient to have an implementation of Arbitrary for types implementing Prime and Field, so that tests can just create values of that type out of thin air and focus on writing the contents of the tests. Let's focus on Prime for concreteness. Something like
#[cfg(test)]
mod tests {
impl<P: Prime> proptest::arbitrary::Arbitrary for P {
// stuff...
}
}
isn't allowed because P is not constrained enough. One solution would be to use newtypes, but I found that messy and confusing. Another solution would be to add a Prime: Arbitrary constraint to the definition of Prime, but that exposes the proptest crate in our public API, and it would become a runtime dependency instead of a dev dependency.
As a compromise, I added a new feature that conditionally adds proptest support, using our MaybeArbitrary trait. This has the added benefit of exposing a mechanism for producing primes to other crates that depend on fp and also want to use proptest. This significantly simplifies the tests for our field types, and streamlines tests for vectors and row reduction.
Using these Arbitrary implementations, I was able to write a battery of tests that check the correct behavior of FqVector over every field and every prime. I'll submit this as a follow-up PR to keep the diff manageable.
The
proptest::arbitrary::Arbitrary
trait lets us create values using a genericany
free function. It would be really convenient to have an implementation ofArbitrary
for types implementingPrime
andField
, so that tests can just create values of that type out of thin air and focus on writing the contents of the tests. Let's focus onPrime
for concreteness. Something likeisn't allowed because
P
is not constrained enough. One solution would be to use newtypes, but I found that messy and confusing. Another solution would be to add aPrime: Arbitrary
constraint to the definition ofPrime
, but that exposes the proptest crate in our public API, and it would become a runtime dependency instead of a dev dependency.As a compromise, I added a new feature that conditionally adds proptest support, using our
MaybeArbitrary
trait. This has the added benefit of exposing a mechanism for producing primes to other crates that depend onfp
and also want to use proptest. This significantly simplifies the tests for our field types, and streamlines tests for vectors and row reduction.Using these
Arbitrary
implementations, I was able to write a battery of tests that check the correct behavior ofFqVector
over every field and every prime. I'll submit this as a follow-up PR to keep the diff manageable.