@ariel.silverman what does "exclusively" mean here exactly? only those keys, and no others? are those qualified keys? do you have value specs too, or is it just keys?

and a due disclaimer "clojure.spec is explicitly designed to discourage closed maps ("no keys except these")"

(it was answered in #beginners )

#datomic query returns a java.util.HashSet, that prints like a set but it's not a coll?. So I cant use s/coll-of on it. I changed my spec from (s/coll-of ::stuff) to seqable? Should spec have a s/seq-of that use seqable? or somethink like that?

https://github.com/slipset/speculative#test-tools

Is running (spec/explain ::foo data-structure) in the beginning of a function bad practise?

I'm using spec/fdef right now and turning on instrument in dev-environment.

Nothing’s bad, just depends what you want

True, I was thinking if there can be some kind of noticeable performance loss if having instrument on in production, but i'll have to measure and see later on.

yes, this definitely affects performance

I don't have any measurements of a real application with instrument on vs. off, but I do have measurements for clojure.set functions with instrumentation on vs. off, for a simple spec that just checks whether the args satisfy set? or not. It is partway down the README on this page: https://github.com/jafingerhut/funjible#wait-isnt-this-what-clojurespec-is-for

I had enabled speculative that has some amount of core specs. My backend + frontend became significantly slower.

instrument in that case is significantly slower than the original functions when their run time is short. The percentage overhead obviously gets smaller as the run time of the instrumented function increases.

I think how may want to use “instrument all” is when I have some weird bug whose stack trace I find uninformative. Then instrument all, run again, find the problem, turn it off.

@borkdude sounds like a solid approach

some specs I do want on all the time in dev, especially at boundaries like DB insert queries

it’s a tweaking process I think

As another data point for the overhead of instrument: clojure.java.jdbc has its specs in a separate namespace and the time difference between running the tests with and without instrumentation -- just on the public API functions -- is huge. I would be extremely careful about turning on instrumentation in production.

Another thing to watch for: if you have a higher-order function instrumented, you'll invoke generative testing on the (function) argument being passed in -- which you almost certainly don't want in production (you probably wouldn't even want org.clojure/test.check included as a dependency in production?).

We've been using s/assert to have dev and production operate differently.