I got it!

i'm now generating all the arguments to the function as a single list

another question! is there any "state" that carries over between instances of generators?

say i define (def string-gen (gen/string))

if i use that in two different overrides, say {::foo (fn [] string-gen)} and {::bar (fn [] string-gen)}

would the two overrides generate strings independently of each other?

I think the generators have seeds? which might be different each time?

ah yes i guess so

along those lines - will a more complex generator retain any sort of state between two invocations?

a top-level generator instance and all its "sub" generator instances share a common source of randomness; it's not shared with other instances

unless you pass it a seed or something? i think

I can’t quite remember

let me google it :thumbsup:

yeah but even then you're regenerating the same randomness independently

it's not shared

ahhhh

yes you are correct

:thumbsup:

so if your overrides are part of a larger generator (e.g. you are generating examples for a top-level map and it has these two keys you override) then the generators share the same source of randomness

if these are independent uses of these generators, they do not share

hmm then why do the overrides have to be wrapped in a function?

it has to be {::foo/bar (fn [] (gen/return inc))} instead of just {::foo/bar (gen/return inc)} right?

does wrapping it in a function kind of force a new generator to be returned or something? to avoid state carrying over?

@ackerleytng wrapping in a function is to allow lazy invocation of the entire generator system; It's possible to use spec without a test.check dependency (e.g. in production) if you don't use any of the generation features.

if you didn't do this, spec would always require test.check even if you only wanted to use e.g. s/valid? s/conform s/unform etc

this is also why clojure.spec.gen.alpha exists: it wraps all the test.check functions and generators so that test.check itself is never required unless actually used

do you usually define generator together with your spec when the only use case for the generator is writing generative tests? It's nice that you can combine them with with-gen, but on the other hand I don't know if it's right to define something in src that's only needed for testing

@blance consider that a generator for foo will be needed for another library that uses foo, and test files are not transitive like source files are

so you end up hacking and adding the generator test files to exported classpath, or rewriting the generator

of those options, a generator in the source file is the least hackish

thanks! that makes me feel better writing generator in along side with the spec itself