Fork me on GitHub

noob question here, how do I make a spec for a fixed length collection of another spec?


Is this a good solution?

(s/def ::my-10-specs (s/and #(= 10 (count %)) (s/+ ::my-spec)))


well, using

(s/def ::my-10-specs (s/& (s/+ ::my-spec) #(= 10 (count %)))
fails after 100 tries


(when generating)


Hi all, Is there a way to see the data that is returned from a function that I call stest/check on? For example, I can see all the data generated for that function’s inputs by passing in a reporter-fn to the opts but I can’t seem to find a way to access that data for the returns. I’d love to pass a function in to format the output data as needed. thx for any pointers!


is there a coll-of?


yes, but it doesn’t work well with s/cat.


oh so you want something that can go in a regex in particular? like (){12} from string regexes? I can imagine a macro that expands to an s/cat with 12 instances of the spec, but that'd be unfortunate. seems like something that could be done better built-in it does seem uncommon though; where did this come up for you?


sorry, that was for @pablore


@fedreg there might not be a supported way, but if you make a TCHECK jira ticket I'll make sure it's at least available to the reporter-fn


Actually, now that I look closer, I don't think this can be fixed in test.check -- it's spec that's hiding the return value


spec creates a test.check property that just returns true when the test passes


@gfredericks Thanks for taking a look!! (and making the ticket!).. Ya, I saw that it was coming back ok from test.check… Seems like there should be a way to see the results… I wonder if the :result is blocked by spec intentionally or if it is just an oversite…


it'd have to be wrapped if anything


spec is returning true, and test.check checks for truthiness; so to test functions that can return falsey you'd have to wrap with {:return ___} or something like that


does stest/check return that true also, or do you only see it in the reporter-fn? I think it's probably only the reporter-fn, in which case I don't see a big downside to spec doing that wrapping


it can't reasonably leak anywhere else, because the return value from a full quick-check run can't include the return value since there's n of them instead of 1 of them


@gfredericks sorry, not sure which true you mean… The return data is evaled here but then just a true is returned if everything is ok. So, if all is good with the specs, just a true is returned. Details only returned if there is a spec validation


If you replaced that line with {:return ret} I think you'd have what you need and nothing else would break


Or at least nothing that wouldn't be easily fixed


But I'm not a spec lawyer so I dunno


Yes... I'll file a ticket. Maybe I'm the only one who would find that useful.. thanks for taking a look regardless @gfredericks !

👍 4

What's going wrong here? It seems odd that args would be treated any differently than the s/valid? checks prior.

user=> (s/def ::any-args (s/cat :name keyword?))
user=> (s/valid? ::any-args [:ok])
user=> (s/valid? ::any-args [1])
user=> (defn foo [aa])
user=> (s/fdef foo :args (s/cat :aa ::any-args))
user=> (dorun (clojure.spec.test.alpha/instrument))
user=> (foo [:ok])

clojure.lang.ExceptionInfo: Call to #'user/foo did not conform to spec:
                            In: [0] val: [:ok] fails spec: :user/any-args at: [:args :aa :name] predicate: keyword?