IMO, with-redefs is always bad form

feel like the more i work through this clojure.spec guide, i’m realizing this is more about typing + generative testing than testing

which is strange given then (s/fdef :fn #()) functionality

or does my mocking have to turn into custom generators

Has any of you ever tried to s/merge two s/keys*? I can only seem to get it to work for validation and not for generation.

Wrote a complete example on SO: http://stackoverflow.com/questions/43388710/generator-for-union-of-two-sets-of-keys-for-named-arguments-with-clojure-spec

Getting some odd validation errors on the :ret with orchestra.spec.test so I’m not sure if the spec is wrong?

comparator fns don’t have to return only -1 / 0 / 1, although a particular one might

they can return any int - the sign is the important thing

comparators also typically have constraints around comparing two of the same kind of things

oh I didn’t know about the sign

I think the issue is I forget fspec is generating data from the args spec and calling the comparator with it, but I have some tricky invariants between a and b that are not encoded inside the args spec

yep

that makes sense, thank alexmiller

Trying to resist the urge to shave that yak but I’m curious what would be the right approach here: a and b only have a partial order, the state that’s being closed over by the comparator is a lookup table that’s used to get a total order. So if I wanted the whole fdef to work, I’d have to constrain the fspec :args generator with the value generated for the fdef :args constructor :thinking_face:

yeah, that’s not likely going to be possible to do easily

but what you can do is to a) build a better args spec that uses values from your lookup and b) write a fn spec that verifies something about the comparator

for a, I mean the generator

and then you also need to ask yourself whether the tests you get out of it are worth the effort you’re putting into the spec. it’s ok if the answer is no. :)

higher order stuff is particularly hard to gen test

I think the answer is no in this case, but I think I understand how this would work: the fspec for the comparator would be checked in isolation so its args need to have the invariants from the lookup table but we don’t need to somehow ensure it’s lexically the same table. So the gen for the lookup table can build the relationships, and the gen for comparable would bind to it and pluck a couple of values out of the table. Is that somehow correct?

yeah, you’d have to close over some of that stuff I guess