Fork me on GitHub

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!


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


is there a version of #(partial instance? %) in core or spec?


apparently not


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


ex: (instance? Cluster), which would be a partial on instance?/2


@alexmiller: would you consider something like this, I'd gladly send a patch for it ?

Alex Miller (Clojure team)11:07:23

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

Alex Miller (Clojure team)13:07:58

I would say that you should consider all implementation details of spec to be just that - subject to change without notice

Alex Miller (Clojure team)13:07:22

spec is meant to provide a relatively complete set of compositional parts, extensible (at the unit level) via predicates

Alex Miller (Clojure team)13:07:10

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")

Alex Miller (Clojure team)13:07:41

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?

Alex Miller (Clojure team)13:07:08

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/conformer date-conformer date-unformer)
    (fn [] (s/gen inst?))))

Alex Miller (Clojure team)13:07:19

@codonnell: thx, I’ll pass along to Rich


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


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




I just saw an email notification from the corner of my eye


"whatever other feature you miss from plumatic/schema” 💯


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


it’s specs all the way down 🙂


a shed to put bike sheds in


I've got some bikes for that shed ...

Alex Miller (Clojure team)20:07:27

@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.

Alex Miller (Clojure team)20:07:45

for -3, if you replace

[`inc-it `print-it]
I think that works

Alex Miller (Clojure team)20:07:27

for -2 and -4, interestingly if you do that instrument and check outside a defn, just at the repl, they work

Alex Miller (Clojure team)20:07:02

(that is, don’t print)

Alex Miller (Clojure team)20:07:27

which implies things about compilation and may be a problem

Alex Miller (Clojure team)20:07:29

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

Alex Miller (Clojure team)20:07:09

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:$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.


There isn’t a danger to calling stest/check within deftest is there?

Alex Miller (Clojure team)20:07:39

is lein or other build tooling involved?

Alex Miller (Clojure team)20:07:52

lein hacks up a lot of the clojure.test stuff


It’s certainly possible – I’m using weavejester’s eftest.

Alex Miller (Clojure team)21:07:40

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.

Alex Miller (Clojure team)21:07:12

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.

Alex Miller (Clojure team)21:07:28

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

Alex Miller (Clojure team)21:07:50

so I’m going to suspect that combination as the most likely probable cause

Alex Miller (Clojure team)21:07:51

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.

Alex Miller (Clojure team)21:07:43

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


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.

Alex Miller (Clojure team)21:07:19

are you explicitly requiring clojure.test.check.clojure-test?


Made myself a couple helpers to simplify tests with check.

Alex Miller (Clojure team)21:07:21

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...


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.

Alex Miller (Clojure team)21:07:22

gimme a sec to look at it

Alex Miller (Clojure team)22:07:29

@kendall.buchanan: looks like this has nothing to do with spec per se

Alex Miller (Clojure team)22:07:39

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

Alex Miller (Clojure team)22:07:06

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.

Alex Miller (Clojure team)22:07:43

so lein test and test.check.clojure-test appear to be incompatible afaict

Alex Miller (Clojure team)22:07:58

you can turn off the monkey patching in lein though

Alex Miller (Clojure team)22:07:02

with :monkeypatch-clojure-test false in your project.clj


Interesting. I’m assuming lein has documented the trade-off of turning it off?

Alex Miller (Clojure team)22:07:03

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…)

Alex Miller (Clojure team)22:07:39

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

Alex Miller (Clojure team)22:07:11

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.

Alex Miller (Clojure team)22:07:55

thx for the good and simple repro! that helped enormously

Alex Miller (Clojure team)22:07:46

@jjcomer I haven’t forgotten yours either - still looking at it


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


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:


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


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