This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-26
Channels
- # bangalore-clj (1)
- # beginners (12)
- # boot (48)
- # cider (56)
- # clara (1)
- # cljs-dev (15)
- # clojure (455)
- # clojure-austin (2)
- # clojure-dev (33)
- # clojure-italy (26)
- # clojure-nl (6)
- # clojure-poland (10)
- # clojure-russia (23)
- # clojure-spec (33)
- # clojure-uk (62)
- # clojurescript (37)
- # code-art (2)
- # cursive (12)
- # datomic (48)
- # funcool (1)
- # juxt (16)
- # leiningen (13)
- # off-topic (12)
- # om (23)
- # onyx (16)
- # other-lisps (5)
- # parinfer (2)
- # pedestal (28)
- # re-frame (60)
- # reagent (8)
- # ring (1)
- # ring-swagger (15)
- # spacemacs (5)
- # specter (53)
- # test-check (2)
- # unrepl (8)
- # vim (14)
@aviflax there are a couple known issues related to s/coll-of and the other collection specs. if you posted your args spec, I might be able to suggest something
@alexmiller great, thank you! I’m working on a gist now — almost done, but having a snag with tools.deps.alpha. Where/how should I report this snag?
@aviflax The jira link for tools.deps is on the readme page
@alexmiller this reproduces and demonstrates my problem and how I’m currently working around it by setting :num-tests
low: https://gist.github.com/aviflax/1a9ba7e73d45157bfc03f6b11c3b9b18
Two things: 1) there is a known issue when using s/coll-of with :kind but without :into (https://dev.clojure.org/jira/browse/CLJ-2103) - this should be fixed soon, but adding your own :into clause will work around it. This could easily be enough. 2) using s/coll-of with a :gen-max option can also help constrain the size of generated collections
actually, #2 may be a non-issue for you since you’re using :count
so I’d recommend in line 20ish, adding :into []
@alexmiller will do — thanks so much!
would a conj talk on test.check be useful? if so, what angle exactly? usage patterns? implementation details? something else? I haven't really considered this before because I figured that reid had already talked about it a few years back and it hadn't changed much since then, but maybe that's not true and/or not a good reason
@alexmiller I added the :into
but it doesn’t seem to have made a difference ¯\(ツ)/¯
Well on the upside, you can rule those out as the problem :)
@gfredericks I'd listen about approaching to property based testing, something in between cookbook and best practices, to improve test-design intuition (what ever that means)
@misha cool; I think that's more or less what I meant by "usage patterns", maybe
@gfredericks a fresher way to go about it might be using spec as reference, how to use and extend generators for specs, and how to write tests using those
yeah, intersecting with spec would probably be more relevant. potentially harder for me since I haven't used spec very much
you can use that as a reason to get more into spec too 🙂
right 😄
@gfredericks the hardest thing I've found with property based testing is figuring out useful properties that can be calculated, without reimplementing the original function
yeah I think that's common. that would fit better as a pure test.check patterns talk
is there a way to do nested/consecutive multi-specs? e.g., {:type :a}
, then also expect :subtype :b
, and now multi-spec based off :subtype
?
You can have a multispec return a spec that is another multispec or you can dispatch on both at the same time using a more complicated dispatch function
@gfredericks a talk on building more complex generators would be very useful and relevant to both spec and test.check
@alexmiller so limiting the scope to generators, enabling a deeper exploration?
I think there is plenty to talk about
Property test patterns is good too but less relevant re spec and has somewhat been done
okay cool; that happens to also be probably the most enjoyable for me to put together
@alexmiller do you have an example of what a multispec returning a multispec would look like? I've tried that and didn't seem to be able to get it to work