This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-10
Channels
- # 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.
@alexmiller any reason why this should happen?
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.
from the doc of s/keyscurrently test.check has a bunch of assertions sprinkled around for checking that the args to particular functions are generators
which is something that could be somewhat accomplished with spec
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
You don't even need the :req there, just (s/keys) is sufficient
@alexmiller I'm pretty sure putting specs in test.check is as feasible as putting them in clojure.core š
I can at least run the test.check test suite with instrumentation
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
thanks, @donaldball I will take a look at that!
The second pinned item in this channel might also be useful
Hi, is there a handy way of writing a s/fdef
for fns with multiple arities (and differing behaviorsā¦)?
(s/alt ::arity-1 (s/cat :a int?)
::arity-2 (s/cat :a int? :b string?))
something like that?I have something like
(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 %)))
and Iād like to disentangle the two aritiesI could wipe a macro to do
(fdef+ my-function
(:args (s/tuple ::x) :ret ::something)
(:args (s/tuple ::x ::y) :ret ::other))
Hi folks, this is my current conundrum: https://www.refheap.com/124571
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 (spec/cat)
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
I just worry that it introduces an extra step each time I make a (spec/ā¦)
call
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 š )
It's possible that we might add something like atom-of
agent-of
ref-of
var-of
future-of
promise-of
generator-of
channel-of
@alexmiller Cool. Do you have any interim advice until that happens? š
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 true
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?
if it's just for testing, then that's not really part of the spec
you might want your generators to be rather more specific/fancy than the specs
more or less because of what you just said
ah, apparently iām not the first: http://dev.clojure.org/jira/browse/CLJ-2074
Is there a preferred way to expression mutual exclusion of the presence of two keys in a map?
Missed this piece on the docs:
> 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.
Heh. Stay out of my brain Brandon!
Yeah. š
Thanks for the thoughts š See you this week, probably.