This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-19
Channels
- # 100-days-of-code (12)
- # beginners (116)
- # calva (2)
- # cider (16)
- # cljdoc (5)
- # cljs-dev (26)
- # clojure (161)
- # clojure-italy (7)
- # clojure-nl (9)
- # clojure-spec (49)
- # clojure-uk (112)
- # clojurescript (50)
- # clojutre (4)
- # core-async (2)
- # cursive (4)
- # datomic (192)
- # emacs (10)
- # events (4)
- # figwheel-main (147)
- # fulcro (94)
- # graphql (5)
- # instaparse (1)
- # jobs-rus (1)
- # keechma (10)
- # leiningen (223)
- # luminus (3)
- # mount (23)
- # nrepl (8)
- # off-topic (44)
- # onyx (10)
- # pedestal (5)
- # re-frame (19)
- # reitit (8)
- # shadow-cljs (62)
- # uncomplicate (3)
what is a good intermediate value for quick-check's :max-size
?
The default kind of takes forever for me for a couple of generative tests
I am afraid 5, which is fast, is too small
yep it is 200
wow, I had to reduce :max-size
to 10
don't even know what or why I am doing this frankly, any feedback is very welcome 😄
a lot depends on what you’re generating and what you’re doing with the generated data. if it’s any thing non-trivial, it’s not unusual for generative tests to take a little while
the slow part is usually generating (too large) input values
I also added a s/coll-of
:gen-max
to 5
the most common thing I find is large collections (default max size per coll is 20) - usually I set :gen-max 3
in all of my s/coll-of’s
recursive / nested specs can also be a problem but less common than the above
I have some kind of nasty :fn
checks:
(s/fdef generate-events
:args (s/cat :options :my-ns/options)
:fn (s/and #(count-matches-number? (-> % :args :options :number) (:ret %))
#(data-nil-or-object? (:ret %))
#(event-key-matches? (-> % :args :options) (:ret %))))
#(and (count-matches-number? (-> % :args :options :number) (:ret %))
(data-nil-or-object? (:ret %)) ...)
right, lemme try that
thanks! didn't thing about that 😄
I imagine evaluating that s/and
spec in each iteration is more expensive than a single predicate
I was able to get up to :max-size 50
with that simple trick, I guess reporting will be different but that's ok for now
so I think this is where it's all clogged...
in ClojureScript too so I don't know, i might be many things
but thanks for the answer
if I go :max-size 20
it is taking more than I can wait for 😄 10
is good
the trick in the tread above by @taylor makes things acceptable again:
:fn #(and (count-matches-number? (-> % :args :options :number) (:ret %))
(data-nil-or-object? (:ret %))
(event-key-matches? (-> % :args :options) (:ret %))))
instead of s/and
(s/valid? any? ::s/invalid)
clojure.spec.alpha/invalid will always fail on spec vaild? so I can't write code like this:
(if-let [x x]
x
::s/invalid)
because if-let
use spec to validate the arguments.there are a few jira issues about it already : https://dev.clojure.org/jira/browse/CLJ-1966
hm I've got a head scratcher. I have two types of keys in a hashmap (keywords and strings). If key is string then spec A
needs to be applied to value, if not then spec B
is applied to value
what's the best way to achieve this
currently I use seq
to change map to sequence of pairs
then it's trivial to spec
@roklenarcic I do that with exclusive maps and I use s/or
you could also use multi specs
(if I understand the problem correctly)
btw, rather than seq to pairs, you can just spec as s/every of s/tuple on the map
that’s a perfectly valid way. alternately, I think given just two choices, I’d lean on s/or over s/multi-spec for this