Fork me on GitHub

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.


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

Alex Miller (Clojure team)14:04:57

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

Alex Miller (Clojure team)14:04:34

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

Alex Miller (Clojure team)14:04:16

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


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:

Alex Miller (Clojure team)14:04:08

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

Alex Miller (Clojure team)14:04:47

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

Alex Miller (Clojure team)14:04:05

for a, I mean the generator

Alex Miller (Clojure team)14:04:34

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. :)

Alex Miller (Clojure team)14:04:01

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?

Alex Miller (Clojure team)16:04:51

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