Fork me on GitHub

I have a question regarding required keysets in combination with or pull queries, where required attributes might be skipped. I have formulated my questions in the following gist:


Hi! I have ns with spec's. how to load all spec names from another ns?


I want to get list of def's from particular ns


@mike1452 you can just require the ns with specs


I want to print on screen available specs


in order to do it I need to get list of spec names


there is (s/registry)


@akiel wow! yeah, sure! thanks!!!


@mike1452 no problem 🙂


I found that some of my spec check were running slowly and causing timeouts. If you find the same thing happening, you can use the options to specify the number of tests you want to run.

(s.t/check `my-ns/my-func {:clojure.spec.test.check/opts {:num-tests 10}})
I hope this helps one of you.


probably had more to do with the volume of data generated than the number of tests


@dacopare As @gfredericks said already: keep an eye on your generators. You can also overwrite them in tests or control them globally with something like :max-gen in coll-of.


@gfredericks: yes, the datastructures that are input and output are very large. Limiting the number of tests is the only way I can see to mitigate this.


@dacopare there are better ways. The :max-gen option mentioned above might do it, I'm not sure. Otherwise there is gen/scale to manipulate the size parameter that a generator sees


heya guys … i’m curious if there’s an idiom for nil-able keys in (s/keys …) wrt other namespaces? what I want to do is something like this:

(ns entity-a)
(s/def ::entity-a (s/keys :req [::b]))
(s/def ::b (s/nilable :entity-b/entity-b)) <— probably wont work

(ns entity-b)
(s/def ::entity-b (s/keys .... (more stuff)))
1) seems redundant to have to define :req [::b] , where ::b is defined locally but just points to another ns 2) ::b should be nilable only from a’s point of view … so I don’t want to put nilable down inside the spec of entity-b … so should this really just be
(s/def ::entity-a (s/keys :req [::b]))
(s/def ::b (s/or :nil nil :val :entity-b/entity-b)


@lwhorton did you consider making the key optional instead of making the value nilable?


i did, but in this particular case the domain is really shoddy. i don’t have time to go refactoring (yet), so entity-a can have the key, but the value might be nil. I suppose that leads to another question - is it more common to just ignore such cases with an opt key, or to capture all possible nil states?


I don't know if there's any sense of what's more common with spec yet


one of spec's core ideas is that the meaning of a key is the same everywhere, which is why you're having to define a different key


which I imagine implies that somewhere you'll have code that translates something to that new key. and if that's the case, then it shouldn't be much more difficult to instead remove the key when the value is nil


good point. or we could just have a proper domain model thought out without monkey patching and quick fixes 😉. thanks @gfredericks


If I have a fn with 2 arguments that are related for correct operation (it’s a fn-var and an argument name), can I use clojure.spec.test/check to check it, or should I write a more traditional clojure.test.check prop?


depends on if you want to make that relationship part of the arg spec or not


via s/and probably


I’m not sure I understand the suggestion; if I do something like (s/and ... is-a-valid-arg-name?) I still need to know the value of the method (and random strings are extremely unlikely to be arg names) — is there something else I’m missing?


in that case you'd need to add a custom generator too


There's no way to use clojure.spec/or or clojure.spec/multi-spec to do what lvh wants here?


@gfredericks just one that applies to the entire arg spec. Makes sense. Thanks 🙂