This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (97)
- # boot (77)
- # cider (7)
- # cljs-dev (47)
- # cljsrn (3)
- # clojure (125)
- # clojure-austin (5)
- # clojure-dusseldorf (1)
- # clojure-italy (4)
- # clojure-russia (91)
- # clojure-spec (80)
- # clojure-uk (54)
- # clojurescript (92)
- # core-async (6)
- # cursive (17)
- # datomic (56)
- # hoplon (7)
- # immutant (3)
- # liberator (3)
- # luminus (4)
- # off-topic (26)
- # om (41)
- # om-next (11)
- # pedestal (3)
- # perun (3)
- # protorepl (25)
- # re-frame (32)
- # reagent (33)
- # ring (46)
- # rum (3)
- # spacemacs (5)
- # specter (82)
- # test-check (16)
- # untangled (8)
- # yada (26)
if I want to use spec for runtime validation, in a situation where my functions accept a large map but only care about a few keys, I should probably create my own validation function rather than using
s/valid? because it validates all of the keys in the map even if I'm looking to only validate a subset of them, right?
@luxbock I don't think so, it will just check what's in (s/keys ...) since map specs are "open" (can contain extra keys) there's no need to check all the entries.
from the doc of s/keys
In addition, the values of *all* namespace-qualified keys will be validated (and possibly destructured) by any registered specs. Note: there is no support for inline value specification, by design.
currently test.check has a bunch of assertions sprinkled around for checking that the args to particular functions are generators
so I'm wondering if it's worthwhile to remove those assertions and just have specs; the downside being that error messages are worse when you haven't instrumented
clojure.test.check.generators, which might not be something that users would naturally do
should library authors expect that users will turn on instrumentation everywhere to debug a problem, and therefore do less runtime validation than they would otherwise do?
@mpenet the whole idea behind s/keys is to register your attributes with known semantics and have them checked throughout your system. By having it validate all keys, your spec grows automatically with your system. If you want to narrow the scope, you can select-keys on the map before validating
@gfredericks: I'm a little worried about the circularity issues of having specs in test.check but maybe it's fine with the dynamic loading gap
I'd say you shouldn't rely on instrumentation in cases where you always want those checks (and this might be one of those places)
it's a bit of implicit vs explicit. So if you use ns keys you can (not that it's a good idea) just use
(s/keys :req ) for your map validation
@alexmiller I'm pretty sure putting specs in test.check is as feasible as putting them in clojure.core 😉
This channel needs a "quicklinks" section for newbs like me. I'm looking for materials on integrating core.spec test.check... can anyone offer me any leads? Is the core.spec workshop from the conj online anywhere?
Someone posted a nice writeup yesterday that might be useful: http://spootnik.org/entries/2017/01/09_an-adventure-with-clocks-component-and.html
Hi, is there a handy way of writing a
s/fdef for fns with multiple arities (and differing behaviors…)?
something like that?
(s/alt ::arity-1 (s/cat :a int?) ::arity-2 (s/cat :a int? :b string?))
I have something like
and I’d like to disentangle the two arities
(s/fdef my-function :args (s/alt :1 (s/tuple ::x) :2 (s/tuple ::x ::y)) :ret (s/alt :1 ::something :2 ::other) :fn #(= (key (:ret %)) (key (:args %)))
I could wipe a macro to do
(fdef+ my-function (:args (s/tuple ::x) :ret ::something) (:args (s/tuple ::x ::y) :ret ::other))
Trying to figure out what the idiomatic way to validate something while "transforming" it, i.e. validate a string using a regex, and then checking that the capture groups have the required values using
Strings would be ideal in that I could avoid a transformation step, but if that would make life easier I'd try it out
is your goal to just get validation of dates/times, or are you looking to leverage spec to generate data, etc.?
Primary goal is to get validation, but if I could get the latter as well I'd be pretty happy
If need be I could write a little transformer fn that turned my string data into, say, a map for easy validation, and another transform the map value into a string to assist with data generation
Another (bad?) option might be some macro magic to allow spec to take a :pre-transform hook
I think what you have now is headed in the right direction. With things like date/time, I always long to use existing libraries. The
clojure.instant library (specifically the
read-instant-timestamp might be of use) can be used to parse a string into a date/time.
for data generation, spec provides
inst-in to generate dates within a range.
Thanks for the suggestion @joshjones. I think I need to take that idea away and hammock on it for a few 🙂
What are folks doing for atoms in terms of spec? I thought I read about an
atom-of function but can’t find any context for that now.
(I recall the “don’t spec atoms, only spec their dereferenced values” advice but that doesn’t help when I have a map that contains two atoms 🙂 )
anyone who has taken a look at this -- http://spootnik.org/entries/2017/01/09_an-adventure-with-clocks-component-and.html could someone explain why authorized-request has a separate, specialized test using a different function spec?
its specifying that the return value is not just a boolean, but specifically that the return is
but how can that be guaranteed since the input is generated randomly based on the spec?
huh. Isn't that beyond the purview of a schema or function spec? Ensuring that data is not only in a given form, but correct according to application logic?
Is there a preferred way to expression mutual exclusion of the presence of two keys in a map?
> The :req key vector supports 'and' and 'or' for key groups: > > (s/keys :req [::x ::y (or ::secret (and ::user ::pwd))] :opt [::z])
It’s not quite mutual exclusion in that both can be absent, but that’s closer.