This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (16)
- # beginners (67)
- # boot (5)
- # cljs-dev (52)
- # cljsjs (2)
- # clojure (94)
- # clojure-spec (34)
- # clojure-uk (10)
- # clojurescript (91)
- # clojutre (1)
- # core-async (20)
- # cursive (5)
- # datomic (1)
- # figwheel-main (70)
- # fulcro (101)
- # hyperfiddle (3)
- # jobs (1)
- # klipse (16)
- # mount (1)
- # nrepl (3)
- # off-topic (24)
- # portkey (39)
- # re-frame (4)
- # reitit (1)
- # shadow-cljs (3)
- # spacemacs (9)
- # tools-deps (5)
From reddit: > There are a couple areas (spec programmability and some map-related stuff) where we have some work to do.
sounds good, despite doesn't say much about what kind of changes. As there are lot of libraries trying to extend spec for different use-cases, it would be great if the need of the libs could be taken into account. Personally would like to see some public spec walking protocols.
@richiardiandrea you can create ns and give it an alias, it will not be tied to an actual file, but you will be able to use that alias to shorten keywords. it is not pretty though.
clojure.core/alias. I found, that having shorter spec names is less tedious and more readable (possible in app layer, where your system is pretty much the only system which sees them). In libraries you probably would want to use longer "truly" global long keywords for under the hood things.
This is an interesting idea, but feels like a hack :) I will give it a try anyways, thank you!
Hi, I am using spec for the first time. And it takes too long to generate my specs using
(test.check/generate (spec/gen ,,, )).
I had previously used
test.check for similar data generation and did not had the problem.
The spec if the configuration map having many nested
:gen-max did not help. What am I doing wrong ?
Heres part of the spec ... the final configuration contains a numbeer of
If you have a lot of s/every, they will gen up to 20 elements. Setting :gen-max in those to something like 3 would probably help
I did try that and it helped.
My question is whether there is a fundamental difference in
spec's data generation and that of
And should I be concerned about using these specs in large generative tests as their size grows ?
spec uses test.check generators so there is literally no difference. There will always be the need to tune the gens a little bit
What’s the preferred way of specing a spec? I have an internal lib function that takes a spec and I want the s/fdef to check that the arg is a spec. So far I have qualified-keyword? But that’s a bit of a shallow spec? Tried spec? But it was returning false on s/def’d qualified keys.
Maybe expect users to wrap in
(s/spec ..) prior to passing argument, then internally spec against
that would also get around the limitation of removing the ability to use a raw predicate
Are there any downsides to that approach? I’m not super familiar with the effects of
get-spec function you can use with the qualified keyword (rather than
s/form). You can wrap anything in
(s/spec? (s/spec 42)) is truthy -- so it won't tell you it's really a spec that is wrapped.
Yeah maybe I need to do some code-based validation rather than relying on the fdef here
It’s not a critical check, I’m just trying to add some guardrails for the other devs that aren’t super familiar with this part of the system
specs can be qualified-keyword?, set?, ifn?, or spec instances (there’s a s/spec? for those)
Should I be using
(spec/fdef ...) for multimethods (does not seem to work)? Guess I can just wrap the defmulti invocation in a function and test that...
Erroneously thought that
multi-spec was for multimethods, but it actually appears to be for dispatching data based on "kinds".