Fork me on GitHub
#clojure-spec
<
2018-08-19
>
pablore04:08:31

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

pablore04:08:06

Is this a good solution?

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

pablore04:08:38

well, using

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

pablore04:08:44

(when generating)

fedreg06:08:07

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!

gfredericks11:08:19

is there a coll-of?

pablore13:08:23

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

gfredericks13:08:25

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?

gfredericks11:08:27

sorry, that was for @pablore

gfredericks11:08:42

@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

gfredericks13:08:39

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

gfredericks13:08:23

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

fedreg15:08:32

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

gfredericks16:08:10

it'd have to be wrapped if anything

gfredericks16:08:33

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

gfredericks16:08:32

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

gfredericks16:08:11

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

fedreg16:08:25

@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

gfredericks16:08:23

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

gfredericks16:08:35

Or at least nothing that wouldn't be easily fixed

gfredericks16:08:54

But I'm not a spec lawyer so I dunno

fedreg16:08:57

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
jeaye22:08:00

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/any-args
user=> (s/valid? ::any-args [:ok])
true
user=> (s/valid? ::any-args [1])
false
user=> (defn foo [aa])
#'user/foo
user=> (s/fdef foo :args (s/cat :aa ::any-args))
user/foo
user=> (dorun (clojure.spec.test.alpha/instrument))
nil
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?