This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-21
Channels
- # beginners (165)
- # boot (9)
- # cider (9)
- # cljs-dev (5)
- # cljsjs (5)
- # clojars (4)
- # clojure (207)
- # clojure-brasil (1)
- # clojure-greece (3)
- # clojure-poland (2)
- # clojure-russia (6)
- # clojure-spec (85)
- # clojure-taiwan (1)
- # clojure-uk (53)
- # clojurescript (96)
- # community-development (2)
- # cursive (4)
- # datomic (14)
- # emacs (41)
- # events (2)
- # hoplon (184)
- # leiningen (1)
- # nginx (1)
- # off-topic (16)
- # om (7)
- # onyx (63)
- # pedestal (27)
- # planck (17)
- # protorepl (3)
- # rdf (9)
- # re-frame (62)
- # reagent (7)
- # ring-swagger (5)
- # schema (2)
- # spacemacs (5)
- # test-check (25)
- # untangled (93)
- # yada (3)
@zane no, although that's been asked a lot
@bbloom: I've done both
@alexmiller besides core, do you use a separate namespace for the separate file?
i guess yes if you want to load them with a require, no if you’re going to load them with load-file from the main ns?
I think it's easier to use a separate ns
@alexmiller one weird thing with that, spec, and namespaced keywords in general, is that i find myself doing this:
There is a patch I wrote to auto-create
So just alias would be enough
Rich hasn't looked at it yet
Well, it's already screened, just waiting for a slice of rich time
@alexmiller defspec-test
worked like a charm. I answered my own SO question for future reference. http://stackoverflow.com/questions/40697841/howto-include-clojure-specd-functions-in-a-test-suite/40711634#40711634
Not planning on it right now
@alexmiller Curious as to why not. defspec-test
, or something similar, seems to be low hanging fruit for adopting spec’d function tests, into a projects overall test suite.
@twashing the one issue with the macro is it only counts generative tests as one test in the test summary (e.g. You run 1000 generative tests but the summary results only count it as one). I've been meaning to add it but haven't had time.
If something like it isn't included in Clojure core when 1.9 is released then we can move it into a micro library instead of a gist
in general, spec tests have a different shape than example based tests. I think it’s good to step back and think about why or if it’s valuable to force everything into the shape of something that clojure.test can run. This feels to me like the limits of our tool (particularly reliance on lein test to run and report everything) are affecting our ability to think about the problem. Why does there need to be only one kind of test runner? Why does there need to be only one kind of test? Generative tests are (by their nature) longer running and often don’t mix well with example based tests in a single suite. There is more to say on this.
Is there a way to use conform
without destructuring the values? (i.e. I’d like have an s/or
within the spec but not have change the original value).
no, but you can use a conformer of val
to undo conforming an or
(s/and ::my-or-spec (s/conformer val))
Rich toyed with s/nonconforming (still there but not in docs) but I suspect it will probably get removed before final release
@bplatz You can fudge it by wrapping your or
spec like this: (s/and (s/or ...) (s/conformer val))
Though this is probably dangerously close to meat grinder territory again 😄
Oops, sorry, I overlooked the first reply of yours @alexmiller
The use case here, which I’d think is a decent one, is validating and coercing JSON input - but downstream code expects data in a specific way.
Thanks for the s/and
tip, I’ll use that for the time being until either it gets officially supported or we just use a different mechanism to coerce the data.
How does one go about speccing a multimethod? Can the different defmethods have different :args
?
I don’t think s/fdef
works on multimethods right now
@alexmiller Ok, but if I don’t use multimethods but dynamically dispatches inside the function, can I somehow define a relation between the function arguments i.e.:
> If the first argument is a number, then the second should conform to :c/myspec1
, but if the first argument is a keyword then the second argument should conform to :c/myspec2
?
there are a couple options
one is to write an fdef
with a :fn
spec which can describe a relationship between args and ret
another is to use s/multi-spec
which can yield a different spec based on a separate multimethod
the latter is really ideal for functions where the spec is open for extension after the fact
I think there are examples of both in the guide http://clojure.org/guides/spec
no, it can be anything
as long as you give it a multimethod that chooses the proper spec based on the input
@alexmiller Ah, just like multimethods the second argument is not a keyword but a function, but in clojure a keyword can be a function… Then that’s exactly what I need.)
you will likely need a custom retag function too, but that’s not a big deal
used during generation
check the docstring for the details
I have a clojure-spec/clojurescript question if anybody can help. I suspect it’s obvious.
I have the following -
(s/def ::box (s/keys :req [::c/height ::c/width ::p/x ::p/y]))
(defn- right [box]
(+ (:width box) (:x box)))
(defn- bottom [box]
(+ (:height box) (:y box)))
(defn intersect? [box-one box-two]
(not
(or
(> (::p/x box-two) (right box-one))
(< (right box-two) (:x box-one))
(> (:y box-two) (bottom box-one))
(< (bottom box-two) (:y box-one)))))
(s/fdef intersect?
:args (s/cat :box-one ::box :box-two ::box)
:ret boolean?)
What I can’t do is get the intersect?
to actually assert when I call it incorrectly
So for instance:
cljs.user=> (require '[cljs.spec :as s])
nil
cljs.user=> (s/check-asserts?)
true
cljs.user=> (box/intersect? {} {::c/width 100})
true
I’m sure the problem is between brain and keyboard, but I’m pretty stumped. Shouldn’t this go kerblooie?
I thought fdef would instrument the function - thereby adding the asserts automagically
when testing you can run instrument, which turns on that sort of thing for testing, but you will also get bits of generative testing happening, so it is not something you generally want to turn on
@paytonrules you want to run (s/instrument)
I was going by this from fdef docs
"Once registered, function specs are included in doc, checked by instrument,
But apparently ClojureScript doesn’t have the instrument function
instrument is in clojure.spec.test (not sure what translation to that you need to do for clojurescript)
Aha - it was the clojure.spec.test that I missed bit that I missed.
Thanks a lot. It would appear then that spec’ing functions that you aren’t actively doing property based testing on, or debugging, may not be a useful endeavor.
@paytonrules I'm not sure that's true, I think there's still value in specing things and having instrumentation turned on for development/test
I wonder how much slower things will be turning on instrument in development will be
unless you're getting into speccing function arguments I don't expect instrument will be super slow in a development context
Maybe to turn it on and turn it off. I’m making an HTML5 game so if I spec everything it’ll hurt.
if you turn on instrument, invoking functions that are spec'ed will also cause those functions to be genertively tested against those specs
@hiredman I'm not sure that's right? I think it only generatively tests functions that you pass as arguments, to make sure the argument satisfies the fdef