This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-22
Channels
- # announcements (2)
- # beginners (42)
- # calva (2)
- # cider (13)
- # clara (2)
- # cljdoc (1)
- # cljs-dev (8)
- # clojure (118)
- # clojure-australia (1)
- # clojure-europe (3)
- # clojure-finland (2)
- # clojure-italy (42)
- # clojure-japan (1)
- # clojure-nl (2)
- # clojure-spec (26)
- # clojure-uk (58)
- # clojurescript (83)
- # cursive (6)
- # data-science (2)
- # datomic (13)
- # devcards (2)
- # duct (9)
- # figwheel-main (4)
- # fulcro (11)
- # graphql (51)
- # jobs (1)
- # juxt (14)
- # kaocha (1)
- # off-topic (24)
- # re-frame (65)
- # reagent (4)
- # reitit (19)
- # remote-jobs (8)
- # shadow-cljs (50)
- # specter (3)
- # speculative (1)
- # vim (5)
- # yada (50)
Is there any way to get more info about why a spec generator is failing? This is the error message:
clojure.lang.ExceptionInfo: Couldn't satisfy such-that predicate after 100 tries. {:pred #object[clojure.spec.alpha$gensub$fn__1876 0x7230d43f "clojure.spec.alpha$gensub$fn__1876@7230d43f"], :gen #clojure.test.check.generators.Generator{:gen #object[clojure.test.check.generators$such_that$fn__45785 0x2ea879fb "clojure.test.check.generators$such_that$fn__45785@2ea879fb"]}, :max-tries 100}
Nothing in the stacktrace points to my code. I guess I could go through and individually test all my specs for which failed but in this case the spec is huge and that would be very time consuming.@kenny not an answer to your direct question, but that particular failure is usually caused by an s/and
, where one of the non-initial predicates is not likely to happen by chance
(or all of them together, more accurately)
it's a long outstanding issue between spec and test.check; test.check's alphas have a feature in such-that
that would let spec report what spec is causing it
but spec doesn't use that feature yet afaik
It doesn't help you now @kenny but when I'm writing specs, I pretty much always have a (comment ..)
form with calls to s/exercise
for each of my specs, and I make sure they generate as I'm writing them... for exactly this reason.
I have some decent guesses for the ones that fail but the feature @gfredericks mentioned would significantly improve this experience. Then you could get rid of all those comment blocks @seancorfield😉
I have a lot of Rich Comment Forms in my code 🙂
I find they're a good way to keep notes about my thinking as I develop, as well as containing expressions that produce test data and show usage of functions -- and specs 🙂
what would be the recommend way to do a multi-spec dispatch for some nested map variable ? e.g. let's say that i have this
{:entity/type :user
:entity/data
{:user/id 1234}}
and i want to multi-spec the :entity/data
based on the :entity/type
... this seems pretty tricky ?because this is not possible, although it's something that i would want:
(s/def :entity/data (s/multi-spec entity-data :entity/type))
(s/def :entity (s/keys :req [:entity/type :entity/data]))
now i could repeat :entity/type
as a property of :entity/data
again, but that seems redundant
If you really have to, you can use multispec with the dispatch on type. Repeat this for all the different types:
(s/def :your/data any?)
(s/valid?
(s/coll-of (s/or :type (s/tuple #{:entity/type} #{:user})
:data (s/tuple #{:entity/data}
:your/data))
:kind map?)
{:entity/type :user
:entity/data :foo})
If you control the design of the data, but i guess you dont, there is probably a better way more in line with clojure.spec
how would you redesign the data ? lift the data inside :entity/data
into the parent map so that multispec works ?
yeah sorry for giving the evil hack 🙂 Changing the data will make it much cleaner. And using multispec for example gives you very nice specific validation errors e.g. when using it with expound
btw, not using a namespaced keyword, so :data
instead of :entity/data
could also be used as a fix instead of lifting the data inside. You would use s/keys
with :req-un
instead of :req