kk thanks @bfabry

I need some advice, I’ve hit a strange situation while trying to writes specs for data coming in from an external source… The source returns a map that roughly translates to this: {:productStatus {:productStatus "active" ...} ...}

how on earth would I spec :productStatus the map, and the string value? I have no control over the output generated by the service

either you overspecify by creating separate nses for each, or use something more generic like map-of, if it's only one key its fine, if that s a lot of keys that s so so

think separate ns’s are maybe the way to go here, will test that out, thanks!

thanks @mpenet! simple, it works, don’t know why I got myself stuck in another loop

This may be highly subjective, but will Spec replace :pre and :post conditions as the idiomatic way to validate inputs and outputs? For example, something like this:

(ns rna-transcription)


(def m
  {\G  \C
   \C  \G
   \T  \A
   \A  \U})


(defn to-rna [xs]
  {:pre [(every? #(contains? m %) xs)]}
  (apply str (map m xs)))

Or will :pre and :post still have their place and time?

I could still see myself using :pre and :post to check non-local invariants, but that'd be pretty uncommon

@jaymartin You could define specs for your DNA/RNA stuff and use s/valid? in :pre...

(s/def ::dna m)
(s/def ::dna-sequence (s/coll-of ::dna))
(defn to-rna [xs]
  {:pre [(s/valid? ::dna-sequence (seq xs))]}
  (apply str (map m xs)))

that looks nice

or go further and define ::dna-string as (s/and string? #(s/coll-of ::dna (seq %))) and then {:pre [(s/valid? ::dna-string xs)]}

(I hardly ever use :pre or :post, I must admit -- but I'm an advocate of leaving assertions on in production if you're going to use them at all)

what do you think about instrument in production? 👀

instrument is a different beast, not least because it can trigger generative testing on higher-order function.

In addition, instrument can introduce a big performance overhead depending on how much is spec'd and how they're written. The specs for java.jdbc are a case in point: they introduce a huge overhead.

Super helpful!

(Hmm, that reminds me that I forgot to add :keywordize? to the optional specs in release 0.7.3!)

thanks!

@guy We're using it in production.

Given our specs, I've measured that we spend about 2% of our time with instrumentation.

As Sean said, that can very wildly, depending on how the specs are written. Primarily whether or not there are a lot of alternate paths which need to be considered.

For us, it's almost entirely clojure.core predicates and s/keys though, so it ends up being very fast and entirely practical for our production builds.

nice thanks @jeaye!