I have question that more experienced people here will likely think obvious. Say I have a map with some keys, two of which need to have the same value. For example m, {::id v1 ::nm v2 ...}, and I want to enforce (= (m ::id) (m ::nm)). I haven't seen this sort of example, but presumably it is covered by spec?? Thanks in advance for any insight!

Hmmmm, this doesn't give errors, but it doesn't work either:

Hmmmm, looks like id-eq-nm? needs to use (m :sid) and (m :snm)

Hey all. I'm writing specs for a few controller functions. They take in request maps and hand off those maps to have work done. The issue I'm experiencing is that a collection inside of that (`body-params`) can vary by quite a bit depending on which endpoint is called and I don't like the idea of writing a really loose spec that can work with all of the say, user endpoints. As such: (s/def ::body-params (s/keys :opt [::username ::email ::....])) and would prefer to have specs setup for each call: (s/def ::body-params (s/keys :req [::email] :opt [:...])). Without putting each endpoint into a new file. How do I go about handling this?

I think this is a problem which spec2 solves

you can watch the latest Rich Hickey talk on youtube if you want to know more

not that this is solving your problem right now… sorry 🙂

Yeah, I saw the talk. I was just kinda hoping that there was something I could do naow

Could a multi-spec be used for this?

(s/def ::email string?)
(s/def ::username number?)
(s/def ::request-type #{:change-email :show-username})

(s/def ::change-email-request (s/keys :req [::email] :opt [::username]))
(s/def ::show-username-request (s/keys :req [::username] :opt [::email]))


(defmulti request-type ::request-type)
(defmethod request-type :change-email [_] ::change-email-request)
(defmethod request-type :show-username [_] ::show-username-request)

(s/def ::body-params (s/multi-spec request-type ::request-type))

(s/valid? ::body-params {::request-type :change-email ::email "boop"})
=> true
(s/valid? ::body-params {::request-type :change-email ::username 1234})
=> false
(s/valid? ::body-params {::request-type :show-username ::email "boop"})
=> false
(s/valid? ::body-params {::request-type :show-username ::username 1234})
=> true

You'll have to do a step first that assigns the request-type key to the map, depending on the controller that was callled

Might be the wrong place to ask, But with https://github.com/jeaye/orchestra are you still supposed to use, https://clojure.github.io/spec.alpha/clojure.spec.test.alpha-api.html#clojure.spec.test.alpha/check To check the instrumented fdef’s?

@guy as far as I know orchestra only changes instrumentation (it includes ret + fn checks). you still define specs with normal spec, so everything should still work. orchestra uses different namespaces, so it doesn’t patch/replace spec itself (I think)

@jeaye might be able to confirm or correct this

Thanks!

Also i’m a little confused about how to use :fn

as part of an fdef

here’s an example: https://github.com/borkdude/speculative/blob/master/src/speculative/core.cljc#L465

Am i supposed to try and link the :args and :ret using :fn ? As in when a certain input is something, then the return should be something, using fn to validate that?

Yep, you still use spec for everything. Just use orchestra to enable instrumentation and consider using defn-spec to clean up your fns.

@guy with fn you can do additional checking on arg + ret and dependencies between them

:fn is optional, so you'll likely know when you need it.

@guy e.g. in the group-by spec I linked I did an additional check that group-by should not produce more elements than the input collection had

❤️ defn-spec

we’ve rolled our own for defrecord, but would like to see standard spec-enhanced forms be a thing. but I have a feeling they’re most useful for those of us using spec as a poor man’s type system, which is probably something Hickey wants to discourage

can you explain what you're talking about?

what is "spec-enhanced forms"?