This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-06
Channels
- # beginners (32)
- # boot (17)
- # cider (4)
- # clara (112)
- # cljs-dev (3)
- # cljsjs (2)
- # clojure (222)
- # clojure-germany (3)
- # clojure-greece (1)
- # clojure-italy (4)
- # clojure-losangeles (4)
- # clojure-russia (46)
- # clojure-spec (24)
- # clojure-uk (71)
- # clojurescript (78)
- # community-development (5)
- # component (88)
- # cursive (6)
- # datomic (7)
- # duct (5)
- # figwheel (2)
- # fulcro (21)
- # graphql (22)
- # leiningen (3)
- # luminus (9)
- # off-topic (1)
- # om (16)
- # onyx (46)
- # portkey (30)
- # re-frame (47)
- # reagent (5)
- # remote-jobs (1)
- # ring (12)
- # ring-swagger (13)
- # rum (1)
- # shadow-cljs (81)
- # spacemacs (1)
- # specter (33)
- # sql (2)
- # test-check (2)
- # vim (16)
- # yada (11)
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)))
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)))
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)
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.
(Hmm, that reminds me that I forgot to add :keywordize?
to the optional specs in release 0.7.3!)
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.