@gfredericks: The thunk is literally producing the generated value. e.g. (fn [& _] (java.util.UUID/randomUUID))
.
I see now that make-gen
doesn't take a thunk (my bad!) but I'm still wondering what the right way to go about this is.
The best thing we could come up with was: (clojure.test.check.generators/fmap (fn [_] (java.util.UUID/randomUUID)) (clojure.test.check.generators/return nil))
But that obviously feels pretty gross since the work of clojure.test.check.generators/return
is discarded.
@zane: would gen/uuid work for you or are you doing something else?
Ah, I don't think gen/uuid
exists in the alpha we're using.
Assuming it doesn't, what would the right workaround be?
(Maybe the answer is: Update your alpha. 😄)
You could generate a collection of hex characters and use gen/fmap to convert then to a uuid
Eek.
You can also generate two longs and build a uuid with it
In general you want to use the randomness of the framework, not calling any random functions yourself, else you lose determinism and shrinking
Ah, my strategy doesn’t ensure uniqueness
Neither does mine
This is what you’d use if you don’t need uniqueness https://docs.oracle.com/javase/7/docs/api/java/util/UUID.html#UUID(long,%20long)
I’ve also used with-redefs to override my internal random uuid generation function, and I just generated the seed via test.check
A bit hacky, but it saved me from having to pass down a UUID seed and changing a lot of code
I'd just copy the code from master probably
mmm