@centril If I wanted to use Arbitrary
outside of proptest to generate test data, how could I make it repeatable? For example, is there a way I can control the RNG and its seed?
@Jake Goulding so what Arbitrary::arbitrary
does is merely return a type that implements Strategy
; A strategy then defines how to generate a ValueTree
(which defines how to shrink + produce values) based on a TestRunner
that it gets as an argument to new_tree
; what the proptest! { .. }
macro does is the setup of the test runner and such behind the scenes
you can tweak the Config
there for example
outside of proptest
i.e. the arbitrary crate (that is related, yeah?)
@Jake Goulding no, that has nothing to do with proptest's version of Arbitrary
that's unfortunate. Now I need to read different docs
Maybe my question would then be... "is it useful to use proptest's Arbitrary
to generate test data outside of directly used in proptest"
proptest and the quickcheck crate's model of property based testing differ entirely; proptest uses value based integrated shrinking and then uses Arbitrary to define canonical strategies for a type whereas the quickcheck crate uses type based shrinking
I am aware of that, but I do not see how that relates to the topic at hand
hmm, lemme think about it a bit
one step higher: I'd like to be able to generate 100MB of XML easily and test speed between my library and libxml
I don't want to check in 100MB files
@Jake Goulding you don't care about shrinking then?
For that, no. But I would love to be able to reuse this code for actual proptesting
where shrinking is much more useful
For speed tests, I'd just want control over the "size"
OK; so outside of the definition of a Strategy, the only control over generation you have is the parameters you can set in https://altsysrq.github.io/rustdoc/proptest/latest/proptest/test_runner/struct.Config.html, e.g. cases: u32
-- if you want to just generate a bunch of <Foo as Strategy>::Value
objects, then you can make a TestRunner::new(my_config)
, instantiate your strategy, and then call new_tree(the_runner).unwrap().current()
a bunch of times
current() should always give you the same thing, so new_tree
is what you use to change the value generated
actually if you want to do this you don't need to touch cases
at all since you are deciding how many to generate
might be useful to add a facility like this to proptest upstream
There will be some overhead cause proptest will include state that is only useful to shrinking
(but useless if you are not interested in shrinking)
@Jake Goulding does that answer the question?
maybe it would be good to have fn values<S: Strategy>(self, strat: S) -> impl Iterator<Item = S::Value>
or something in TestRunner
It sounds like I should file an issue, to see if folk would find this or something similar useful
@Jake Goulding yeah please do
(and cc me)