This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-24
Channels
- # aws (7)
- # aws-lambda (3)
- # beginners (65)
- # boot (43)
- # cider (7)
- # cljs-dev (12)
- # cljsrn (15)
- # clojure (284)
- # clojure-austin (32)
- # clojure-brasil (4)
- # clojure-dusseldorf (4)
- # clojure-germany (1)
- # clojure-italy (40)
- # clojure-spec (21)
- # clojure-uk (69)
- # clojurescript (97)
- # core-async (11)
- # cursive (19)
- # data-science (1)
- # datascript (6)
- # datomic (30)
- # dirac (2)
- # emacs (4)
- # events (2)
- # fulcro (76)
- # graphql (38)
- # juxt (1)
- # lein-figwheel (1)
- # leiningen (6)
- # luminus (4)
- # lumo (13)
- # mount (4)
- # off-topic (24)
- # om (28)
- # onyx (32)
- # other-languages (1)
- # parinfer (40)
- # pedestal (1)
- # portkey (47)
- # re-frame (21)
- # reagent (4)
- # ring (4)
- # ring-swagger (3)
- # rum (1)
- # shadow-cljs (115)
- # spacemacs (5)
- # sql (14)
- # unrepl (1)
- # yada (3)
Where is a good place to put (test/instrument)
so that all my spec’ed functions are instrumented in dev? I have a fairly standard Luminus-based webapp.
@drewverlee I had to do this for the spectacles library, see here: https://github.com/stathissideris/spectacles/blob/master/src/spectacles/impl.clj#L4-L36
@stathissideris @drewverlee there is also a parse-spec
in spec-tools doing about that: https://github.com/metosin/spec-tools/blob/master/test/cljc/spec_tools/parse_test.cljc#L28-L39
@ikitommi do you think we could use spec to parse spec forms or would reality collapse under the weight of self-reference? 😄
way ahead of us 🙂
but even when the spec-of-specs ships, we still need to utilities to do something with the parsed data, e.g. collect keys out of (s/merge ::a-map ::another-map)
, spec-tools is one bin collecting this kind of stuff. And there are many others.
so am I
That'll do the trick, allowing you to specify bits in your leiningen profiles and then conditionally bring in code by reading the profile using environ in a macro.
thanks, the only caveat is that any namespaces you want to instrument must have already been loaded before that’s called, right?
Our my-app.core
requires every model ns we have. Our my-app.core-views
requires every view ns we have, as well as requiring my-app.core
(so view code isn't needed for unit testing).
I wouldn’t imagine so, was just curious what other people’s approaches to that might be. I was thinking another approach would be to just put the (conditional) instrument
calls at the bottom of each spec’d namespace
Hm, that would be every single ns for us, which seems less manageable. Sounds like it would work though, if that's your preference.
Thanks, @U4986ECDQ, seems like a reasonable solution. Those are some handy macros! :thumbsup: