This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-20
Channels
- # aleph (2)
- # boot (18)
- # cider (3)
- # cljs-dev (14)
- # cljsrn (28)
- # clojure (428)
- # clojure-austin (3)
- # clojure-hk (1)
- # clojure-ireland (5)
- # clojure-mexico (1)
- # clojure-quebec (2)
- # clojure-russia (49)
- # clojure-spec (138)
- # clojure-uk (45)
- # clojurescript (70)
- # core-async (1)
- # cursive (8)
- # datomic (13)
- # defnpodcast (3)
- # devops (1)
- # editors (4)
- # events (1)
- # funcool (14)
- # hoplon (17)
- # jobs-rus (1)
- # luminus (5)
- # mount (51)
- # off-topic (21)
- # om (9)
- # om-next (8)
- # onyx (43)
- # planck (6)
- # re-frame (13)
- # reagent (18)
- # ring-swagger (1)
- # spacemacs (17)
- # untangled (18)
- # vim (13)
- # yada (21)
those generated emails are amusing 🙂 i’ve noticed that generated tests tend to have pretty wacky looking data - i guess that’s good for tests, but i can’t help but wonder: what about “example data”? anybody taken a crack at that? would be cool to lorum ipsum up a full database based on specs!
i second that, @bbloom
Sometimes specs seem to dereference themselves... e.g. (s/def ::k (s/keys :req [::foo ::bar]))
dereferences ::foo ::bar
but I've noticed that for example (s/merge ::k ,,,,)
blows up... instead you need to bind :k
to a real var... i.e. it won't dereference the keyword into the specs value.
I'm just wondering if this is by design? And what the reason is... and how to know what to expect
actually this does make a lot of sense... sorry being stupid... keys
/`:req` requires knowledge of the keys themselves... and clearly giving keywords symbol semantics would be insane
I guess you have to rely on the doc strings and specs specs... to know the difference between a spec and a keyword... I guess it's kinda like the distinction between quoted and unquoted symbols... I've only just got started with spec - so knowing when to use which isn't entirely clear to me
I guess this could even simply be another arity of instance?, given how common this is
yeah I've written that one more than a few times
@alexmiller: would you consider something like this, I'd gladly send a patch for it ?
No thanks, has been considered by Rich
are the lower-level details of clojure.spec, in particular the implementation of s/keys, meant to be public so that users/libraries can use them to write new kinds of specs?
it might just amount to implementing a protocol, in which case the question is if the protocol is meant to be public
I would say that you should consider all implementation details of spec to be just that - subject to change without notice
spec is meant to provide a relatively complete set of compositional parts, extensible (at the unit level) via predicates
which is not to say that extending via the protocol is necessarily wrong, just that we’re not committed to maintaining that api, so use at your own risk (like any other Clojure “internals")
the public api is what’s in the api docs
@alexmiller: is there a reason with-gen
does not pass along the unformer function to its return value?
don’t know - example?
are there improvement coming to prevent having to manually create non existing kw namespaces?
;; conform works, unform fails, gen works
(def date-spec
(s/with-gen
(s/conformer date-conformer date-unformer)
(fn [] (s/gen inst?))))
@codonnell: thx, I’ll pass along to Rich
no problem
and next in my wish list of stuff that will not happen for sure is a partially applied version of satisfies?
😆. Probably an opportunity for a lib with helpers like these
knock yourself out
on that note
that would be a fantastic name
well I'm doing it right now
any idea how to write a spec to check an aggregate value of a collection? eg: (s/valid? (= 5 (partial reduce +))) or something like that.. nvm mybad: (s/conform #(= 5 (reduce + %)) [2 3])
lvh: ^ I finally created schpec
it’s distracting to see how many layers deep you can go — I was trying to do something useful with swagger specs and now I’m explaining to clojure.spec how json schema works so I can generate json schemata so I can generate specs from them so I can generate instances of those specs and then see if they match the original json schema
a shed to put bike sheds in
@jjcomer: read the instrument
docs carefully - "Instruments the vars named by sym-or-syms”, "Opts for symbols not included in sym-or-syms are ignored.”, etc - I think that right away rules out your -3 and -4 examples. I’ll look closer at -2. Some of this stuff really makes most sense when instrumenting a ns or all and passing an opts map that sets up the env you want.
for -3, if you replace
`inc-it
with [`inc-it `print-it]
I think that worksfor -2 and -4, interestingly if you do that instrument and check outside a defn, just at the repl, they work
(that is, don’t print)
which implies things about compilation and may be a problem
yeah, when the compiled class is loaded, the var has not yet been altered by instrument and that’s what is loaded into the class constants and used at runtime - the instrumented version of the var is not used
nah that doesn’t make sense - check takes the symbol, not the var and resolves at runtime
I suspect I’m doing something wrong, but I’m reliably getting errors like this:
java.util.concurrent.ExecutionException: java.lang.ClassCastException: app.business.klass_test$eval75458$fn__75459 cannot be cast to clojure.lang.MultiFn, compiling:(clojure/test/check/clojure_test.cljc:95:1)
From stest/check
.
It’s typically when I restart the REPL and try to run check
from my test files (without first navigating over and evaluating the functions it calls). Note I’m requiring the namespaces first.
Thoughts?
I haven’t seen that - looks like it points to https://github.com/clojure/test.check/blob/master/src/main/clojure/clojure/test/check/clojure_test.cljc#L96
There isn’t a danger to calling stest/check
within deftest
is there?
shouldn’t be
is lein or other build tooling involved?
lein hacks up a lot of the clojure.test stuff
It’s certainly possible – I’m using weavejester’s eftest.
does it happen if you don’t?
It happens if I simply eval the form, yes...
But it’s a fairly large project – it’s possible something else is intruding.
eftest is definitely also mucking with clojure.test/report
Yeah, it’s a touch thing – if I go to the test namespace, require everything, and run a single form, it works.
But if I restart the REPL, go to the namespace, eval everything all at once, it falls apart.
K, thanks. Helps to know it’s likely in my environment. I’ll report back when I find it.
But yeah, only happens on check
.
both eftest and check are bashing the same clojure.test hook for reporting and that seems to be in the realm of the error you’re seeing
so I’m going to suspect that combination as the most likely probable cause
I guess not “cause”, I don’t understand why the two together fails but I suspect that’s involved
Okay, great insights. I’ll start by disabling eftest.
if you can get a reproducible case that fails with both, feel free to file a jira and maybe one or the other can be made more tolerant/harmonious
Okay...
Disabling eftest altogether had no effect:
That’s after taking any reference to eftest out of project.clj
, and running lein test
on its own.
I’ll keep poking around.
are you explicitly requiring clojure.test.check.clojure-test?
maybe to use defspec?
Made myself a couple helpers to simplify tests with check
.
unless you’re loading it, it’s not clear to me why clojure.test.check.clojure-test is getting called at all. nothing in core calls it. Your definition above won’t call it, yet you are compiling it. are you AOT’ing?
Seeing if I can create a reproducible lein project...
No AOT.
Cool, just reproduced it.
Very well could be lein, cause I have a barebones example.
I’m happy to post to JIRA too if you feel like it’s a legit reproduction.
gimme a sec to look at it
@kendall.buchanan: looks like this has nothing to do with spec per se
clojure.test.check.clojure-test assumes that clojure.test/report is a multimethod (which it is in core) and modifies one of it’s cases - this is loaded as a side effect when clojure.test.check is loaded via gen via spec.test/check
however, Leiningen monkeypatches core and replaces that clojure.test/report function with something that’s not a multimethod
I noticed the project threw off another error about gen being missing… until I added the test.check
dependency.
so lein test and test.check.clojure-test appear to be incompatible afaict
you can turn off the monkey patching in lein though
with :monkeypatch-clojure-test false
in your project.clj
@gfredericks: ^^ you aware of any of this?
Interesting. I’m assuming lein has documented the trade-off of turning it off?
I think you then lose “lein retest"
Not sure I’d ever have known to look to lein for this… is it appropriate to introduce this into spec docs as a “gotcha”? (just curious how you guys deal with things like this…)
maybe, I was not aware of it before. the master version of test.check actually doesn’t load clojure-test anymore, so you wouldn’t even see this come up unless you included it explicitly
I gotta go, but will think about it more tomorrow
Okay, I am loading explicitly in my project as well… good point.
@alexmiller: Thanks much for spending so much time on that.
Big help.
thx for the good and simple repro! that helped enormously
@jjcomer I haven’t forgotten yours either - still looking at it
@alexmiller: thanks :)
alexmiller: I've been using lein-test
with test.check.clojure-test
for years, so I assume it's something subtler than a full incompatibility. I wasn't aware of this before, no, so I'll look into it
@alexmiller: One final note: turning off monkeypatching fixed it. Turning eftest back on broke it again.
It’s a great start, though, to at least know where it breaks down.
kendall.buchanan: I'm trying to reproduce it now
kendall.buchanan: any tips beyond "using test.check and lein test
"?
gfredericks: Did you clone the repo above?
oh no, didn't see it
That should be everything you need: https://github.com/kendagriff/check
I think the odd thing about stest/check
, though, is it requires test.check
, explicitly.
Otherwise you get errors saying generators are missing.
what do you mean by "explicitly"?
Added to the list of dependencies.
It’s a function that can’t run without the user having to introduce another dependency.
@seancorfield seems to have identified the same thing in a slightly different context: http://dev.clojure.org/jira/browse/CLJ-1936
stest/check
is explicitly about generative testing, right?
Yes, it tests function specs.
I'm not sure how it could make sense to run that without test.check available, given the underlying "test.check is optional" design decision
(It’s the only way to test the return values of functions, afaik.)
Okay, I figured as much.
kendall.buchanan: I still don't quite understand how this happens (or rather, why it doesn't happen all the time), but I can at least tell you it's fixed on test.check master
I'm hoping to make a new release soon
Wow, that’s fantastic.
That’s great news, thansk.
oh actually I get it
I think lein does the monkeypatching after all the requires get loaded
so this is only a problem if you (or something) loads the test.check.clojure-test namespace later (at runtime)
@gfredericks: Just curious… if stest/check
is all about generative testing, why is it in clojure.spec.test
? Does it not make more sense to move it to test.check
(making one aware of the other, but not in both directions)?
kendall.buchanan: that might be possible; but spec might be too tied together with test.check to make that practical
Makes sense.
kendall.buchanan: http://dev.clojure.org/jira/browse/TCHECK-113
I'm not planning to investigate it anymore (I considered closing the issue immediately after creating it) until I hear that it's a problem for someone on test.check master somehow
I figured I'd create the ticket to document the problem for future historians though