let in particular is a macro, and the only macro of the test.check generators

and it looks like the patch doesn't lazy-load it, it completely reimplements it, with different behavior

I'm not sure if lazy-loading a macro is even possible

hi guys, is there any good way to test all fdef in my project instead of using clojure.spec.test.alpha/check for each one explicitly.

@nxqd: guessing you mean fdef not fspec but if you call check with 0-args it should run all var specs that have been loaded

Hmmm… wondering if generator errors like ExceptionInfo Couldn't satisfy such-that predicate after 100 tries. clojure.core/ex-info (core.clj:4725) would be better if they told you which generator/spec failed to generate a value. The stack trace doesn’t seem to contain many useful clues.

Would be nice if the ex-info data contained something like {:generator #function[foo.bar/bar-gen] :spec :foo.bar/valid-bar?}

Hmm also just noticed a small problem with check which is that you can’t both run it on all fdefs and provide custom options

ahh its ok checkable-syms is exposed so can do it by hand

@gfredericks: Do you know if test.check 0.10.0-alpha2 is compatible with the latest clj 1.9 / spec?

@rickmoynihan should be, yeah

awesome

Are we not supposed to be able to add generators to predicates? Is that a closed set?

(That is, if I define a predicate, am I not able to add a generator for it?)

@peeja I'm not sure what you asked, but I think you might want to check (s/with-gen)

then you can set any generator you want to your spec, no mater the predicate

Right, I mean I want to register that as the generator to use everywhere (if it's not overridden)

I'm missing something about combining s/and and s/or: ` (s/def ::identifier (s/and (s/or :keyword simple-keyword? :symbol simple-symbol?) graphql-identifier?))

@peeja what you can do is define a spec, and then re-use that spec instead, eg:

(s/def ::my-spec (s/with-gen my-pred? #(gen-fn)))

(s/def ::other-spec ::my-spec)
(s/def ::another-one (s/and ::my-spec other?))

then it will inherit the generator

@hlship on the and case, the next predicate will receive the conformed version from the previous one

(s/explain ::identifier :foo) java.lang.ClassCastException: clojure.lang.MapEntry cannot be cast to clojure.lang.Named ` I'm guessing that the entire map conformed by s/or (e.g., {:keyword :foo}) is being passed to graphql-identifier? (which expects a String, Keyword, or Symbol). So, what's the correct way to deal with this situation? I'd rather not do the identifier check first. I guess I could change graphql-identifier? to expect the conformed result from the s/or?

so, your graphql-identifier? will receive something like {:keyword :bla} or {:symbol some-sym}

@wilkerlucio Yeah, that makes sense. I was hoping to do it straight on the predicate because it looks like a nicer API, but if that's not how it's meant to work, then that works.

It seems like it gets the Map$Entry, e.g, [:symbol foo].

@peeja if you look at the sources for the spec generators, it uses a map to convert from symbol -> generator, I guess we can suggest this to be replaced with a multi-method making it extensible from the outside

ok, I'm on that track.

@peeja check this: https://github.com/clojure/spec.alpha/blob/master/src/main/clojure/clojure/spec/gen/alpha.clj#L132-L185

Is there any way to use with-gen without blowing away generator overrides?

It seems like it can't, since it doesn't have access to the overrides like gen* does

Are we meant to define our own macros a la keys/`map-spec-impl` etc?