thanks!

still, I find the below bit unintuitive: without :conform-keys the first one informs of error but the second one does not:

(s/conform
  (s/map-of keyword? keyword?)
  {“key” :value})
; :clojure.spec/invalid

(s/conform
  (s/map-of (s/and (s/conformer keyword) keyword?) keyword?)
  {“key” :value})
; {“key” :value}

@ikitommi Why would a string conform to a keyword?

because of the conformer. If I set the :conform-keys it conforms ok as Alex pointed out. But without it, the conform returns invalid data, which feels odd given the s/conform docs: “Given a spec and a value, returns :clojure.spec/invalid if value does not match spec, else the (possibly destructured) value.“.

Seems like you're ignoring the map-of docstring

There are several good reasons not to conform the keys by default

what's the point of clojure spec's fdef ? If I check against my specs using pre & post-conditions, I will get failures at the point of invocation, but having defined a function spec doesn't really prevent the function returning a non-compliant value (and I assume the same is true for providing wrong input)

(aside from stubbing dependent functions for tests)

For use with stest/instrument and stest/check

That's it ? The spec guide hints at fdef providing something for development, I can't temporarily get more feedback during development ?

@pseud Isn't instrument meant for development - you can instrument a function so that it check its input, output when called?

instrument only checks input for fdef if I remember correctly

But yeah, it's meant to give more feedback during development

there's https://github.com/jeaye/orchestra if you want to check :ret and :fn as well

having trouble composing a few simple specs. seems to work until I use the range spec listed in the snippet.

also, if I compose :oic/core with something that does not include this range spec, it works ok.

background: converting json schemata like this to spec: https://github.com/OpenInterConnect/IoTDataModels/blob/master/oic.baseResource.json

is there a way to make check stop on first failure?

same thing happens with (s/def ::step (s/or :i integer? :n number?))

Is it possible during tests to have an fdef check its args but skip checking with exercised inputs?

is this a bug?

(s/def ::foo number?)
(s/def ::bar (s/or :i integer? :n number?))
(s/def ::baz (s/and (s/keys :opt [::foo]) (s/keys :opt [::bar])))
(s/explain ::baz {::foo 1 ::bar 9})
;; In: [:oic.r/bar] val: [:i 9] fails spec: :oic.r/bar at: [:oic.r/bar :i] predicate: integer?
;; In: [:oic.r/bar] val: [:i 9] fails spec: :oic.r/bar at: [:oic.r/bar :n] predicate: number?

No. s/and flows the conformed value through subsequent forms.

(s/conform (s/keys :opt [::foo]) {::foo 1 ::bar 9}) ;=> #:boot.user{:foo 1, :bar [:i 9]} — s/keys conforms all key/values if there are specs for them, not just the keys listed in :req and :opt.

^ @mobileink

You want s/merge here to combine key-specs:

boot.user=> (s/def ::baz2 (s/merge (s/keys :opt [::foo]) (s/keys :opt [::bar])))
:boot.user/baz2
boot.user=> (s/explain ::baz2 {::foo 1 ::bar 9})
Success!
nil

d’oh! thanks, he mumbled sheepishly.