This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-13
Channels
- # beginners (42)
- # boot (33)
- # cider (4)
- # clara (1)
- # cljs-dev (2)
- # clojars (3)
- # clojure (207)
- # clojure-boston (1)
- # clojure-france (3)
- # clojure-india (7)
- # clojure-miami (1)
- # clojure-nl (8)
- # clojure-poland (13)
- # clojure-russia (102)
- # clojure-spec (22)
- # clojure-uk (37)
- # clojureremote (15)
- # clojurescript (229)
- # cursive (9)
- # datomic (1)
- # emacs (7)
- # figwheel (2)
- # funcool (1)
- # garden (1)
- # hoplon (7)
- # jobs (12)
- # jobs-discuss (27)
- # juxt (2)
- # leiningen (6)
- # luminus (9)
- # lumo (18)
- # off-topic (3)
- # onyx (9)
- # re-frame (54)
- # reagent (5)
- # remote-jobs (3)
- # ring (3)
- # rum (3)
- # specter (28)
- # yada (30)
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
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
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