Hey guys, sorry for the slow reply. I had ended up with this:

(s/def ::age (s/with-gen (s/and integer? pos? #(< % 100)) (clojure.spec.gen.alpha/large-integer* {:min 0 :max 100})))

@petr Did you see my suggestion of using s/int-in?

user=> (require '[clojure.spec.alpha :as s])
nil
user=> (s/def ::age (s/int-in 1 100))
:user/age
user=> (s/exercise ::age)
([1 1] [1 1] [2 2] [2 2] [1 1] [6 6] [5 5] [1 1] [16 16] [7 7])
user=> (s/exercise ::age)
([1 1] [2 2] [1 1] [3 3] [8 8] [2 2] [2 2] [9 9] [2 2] [69 69])
user=>

what is the practical purpose of s/key’s :opt and :opt-un? - documentation(?) - include :opt keys during s/exercise - anything else? does s/conform conforms all known keys in a map, or just listed in :req/:opt/-un?

in my understanding it's that the presence of the key is optional, but if it's present, its shape has to fulfill its spec

^

Thats what ive used it for before

@vale s/keys checks against all the known key-specs, you dont have to list them in the s/keys. empty s/keys will test all the registered keys

are you sure about that?

yes

this is one of the goals or benefits of having global specs registry and namespaced keywords

(s/def :foo/bar int?)
=> :foo/bar
(s/valid? (s/keys) {:foo/bar 1})
=> true
(s/valid? (s/keys) {:foo/bar "1"})
=> false

i see... well it's still meaningful for the un ones where you have to be explicit

otherwise the opt is probably just for what you said

true

anything else?

>you dont have to list them in the s/keys. I thought part of the reason u list them in s/keys is to show easily what the shape of the data is?

using (s/keys) like you did seems to be interesting, i’ve never seen that before

@guy “show” is documentation + exercise I mentioned above

oh right sorry

:thumbsup:

yeah i think uve covered it imo

I’d not use empty s/keys, it is just an illustration

does anyone have a good way of writing specs for ring middleware?

for every middleware function along the chain, the inputs and outputs change

seems tedious to spec all the middleware functions

you shouldn't have to fully describe the req/resp at each point though; you could describe just what's pertinent to that piece

do you mean like... if this middleware augments the request with a new key value pair

then perhaps the :args request should be just map?

and the :ret is like a function with :args including just the new key-value pair?

sort of like only writing spec for the change in this particular middleware?

yeah

you could also write a :fn saying everything else gets passed through

thanks!