Fork me on GitHub
Alex Miller (Clojure team)01:07:13

@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?

Alex Miller (Clojure team)15:07:57

@aviflax The jira link for tools.deps is on the readme page


Got it — will report there. Thanks!


@alexmiller this reproduces and demonstrates my problem and how I’m currently working around it by setting :num-tests low:

Alex Miller (Clojure team)16:07:05

Two things: 1) there is a known issue when using s/coll-of with :kind but without :into ( - 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

Alex Miller (Clojure team)16:07:24

actually, #2 may be a non-issue for you since you’re using :count

Alex Miller (Clojure team)16:07:52

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 ¯\(ツ)


adding :gen-max doesn’t seem to make a difference either 😞

Alex Miller (Clojure team)23:07:18

Well on the upside, you can rule those out as the problem :)


Should I open a JIRA ticket?


I’ve shrunk down the example just a bit by removing the CSV parsing… it’s still slow 😓


@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 🙂


@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?

Alex Miller (Clojure team)23:07:34

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

Alex Miller (Clojure team)23:07:38

@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?

Alex Miller (Clojure team)23:07:58

I think there is plenty to talk about

Alex Miller (Clojure team)23:07:32

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