This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-25
Channels
- # aws (1)
- # bangalore-clj (9)
- # boot (97)
- # capetown (1)
- # cider (4)
- # clara (1)
- # cljs-dev (2)
- # cljsrn (109)
- # clojure (258)
- # clojure-finland (3)
- # clojure-greece (2)
- # clojure-italy (1)
- # clojure-russia (33)
- # clojure-spec (41)
- # clojure-uk (46)
- # clojurescript (57)
- # component (17)
- # core-async (6)
- # datomic (13)
- # devcards (10)
- # dirac (2)
- # euroclojure (1)
- # figwheel (1)
- # funcool (1)
- # hoplon (472)
- # luminus (17)
- # off-topic (1)
- # om (16)
- # onyx (40)
- # pedestal (14)
- # proton (12)
- # re-frame (27)
- # reagent (15)
- # ring-swagger (2)
- # specter (5)
- # testing (4)
- # untangled (258)
- # vim (4)
what is the idiomatic way to write specs? in a spec
directory? how do you run them? is there a lein spec
like lein test
? how do you guys do that? i guess specs are not just to be run in a repl while developing..
Specs are code. You can either put them inline with your other code or in a separate namespace.
You can use them in a variety of ways
If you want to use them in your production code you can call s/conform or s/valid?
If you want to be able to toggle them on or off you can use s/assert
If you want to use them during testing you can use stest/instrument (to check calls to a function) and stest/check to generatively test a spec'ed function
I think I may have run into a bug in conform
:
(s/def ::mapping-offset
(s/cat :offset nat-int? :length nat-int?))
(s/def ::mapping-offsets
(s/map-of ::mapping-offset ::mapping-offset))
(s/conform ::mapping-offsets {[0 3] [4 3]}) => {[0 3] {:offset 4, :length 3}}
Easy enough to work around using s/tuple
instead of s/cat
, but figured I’d mention it here. Should I file a bug report?
no, that’s expected behavior
you can pass :conform-keys true
as additional map-of options to get both conformed
default is false (as often you don’t need it, and there’s a perf cost, and there’s the possibility of conformed keys overlapping and losing data in the conformed map)
this is in the docstring for map-of
too
I’m assuming that you were objecting to the vals being conformed but not the keys
if you actually want neither conformed, you can do that with a conformer on the val spec
or change it to use tuple as you suggested
Hey @alexmiller, I think there's a bug in (s/form (s/every pred ...)). (s/form (s/coll-of (s/keys :req-un [:PROJ_CONTACT/NAME])))
returns a pred of s/keys
instead of clojure.spec/keys
.
yes, there’s a ticket and a patch waiting for Rich already on that
Thanks Alex.
that patch was super annoying with all the macrology - it’s hard to tell but I put a lot of work into making that as small a change as it is
That code is quite tricky.
While you're about. I'm interested in finding a good approach for walking through specs to transform. In my case I'd like to use specs to produce a simple version of a datomic pull query.
This is what I have https://gist.github.com/olivergeorge/8368ab3637d0ade128166de78bac7903
I suspect there's a slightly more artful approach. Any chance you can point me at an example.
so one thing that is coming (and is behind all my spec form fixes) is specs for s/form’s return, basically specs for spec forms, which is the path you’re on there
@olivergeorge so I think using spec to conform spec forms is imo a good approach
I am having some trouble getting a test that uses promises wired up to be the body of a property. (the example i am extending is here https://github.com/clojure/clojurescript/wiki/Testing#async-testing and here https://github.com/clojure/test.check#clojurescript)
@alexmiller Thanks. The spec form specs (!) sound useful. Perhaps those could be the basis for post-walk wrapper or zipper. I'm thinking that might make walking/transforming the spec tree less quirky.
Nice to know i'm on the right track. Much appreciated.
Thanks, alexmiller, I should have checked the docstring first.
is (s/keys)
the best way to express s/map-of
-style varargs?
assuming my key-spec is keyword?
of course
@gfredericks s/keys* is for varargs
yeah I did
in particular I mean (s/keys*)
with no args
Why no args?
I mean, that's fine but opt-un is useful on the gen side