Fork me on GitHub
#clojure-spec
<
2017-02-20
>
akiel10:02:07

I have a question regarding required keysets in combination with om.next or pull queries, where required attributes might be skipped. I have formulated my questions in the following gist: https://gist.github.com/alexanderkiel/81daedb133f7939d0c88ff28dd457442

mike_ananev14:02:55

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

mike_ananev14:02:32

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

akiel14:02:19

@mike1452 you can just require the ns with specs

mike_ananev14:02:23

I want to print on screen available specs

mike_ananev14:02:57

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

akiel14:02:11

there is (s/registry)

mike_ananev14:02:18

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

akiel14:02:02

@mike1452 no problem 🙂

dacopare15:02:57

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.

gfredericks15:02:58

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

akiel15:02:16

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

dacopare15:02:02

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

gfredericks15:02:40

@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

lwhorton16:02:35

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

gfredericks16:02:46

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

lwhorton16:02:32

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?

gfredericks16:02:00

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

gfredericks16:02:26

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

gfredericks16:02:04

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

lwhorton16:02:09

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

lvh20:02:31

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?

gfredericks20:02:40

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

gfredericks20:02:48

via s/and probably

lvh20:02:29

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?

gfredericks20:02:08

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

zane20:02:35

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

lvh20:02:29

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