@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