Fork me on GitHub
Matt Butler10:07:30

Is there any way to use predicates inside the literal comparator to achieve something like this in spec. (s/valid? #{["foo" "bar" string?]} ["foo" "bar" "baz"])


you could spec that with s/cat

Matt Butler14:07:05

so (s/tuple #{"foo"} #{"bar"} string?) ? but if I wanted to combine that with other fixed values where I know all 3 elements, I'd have to use an s/or like so? (s/or :set #{["a" "b" "c"]} :tuple (s/tuple #{"foo"} #{"bar"} string?))

Matt Butler14:07:20

There is no way to next dynamic values inside the #{}

Matt Butler14:07:57

Thanks btw 🙂 jut wanted to check my understanding.


if I understand the use case, s/or seems reasonable to me

Matt Butler14:07:54

Yeah I have a set of triple store values, most are known but for some subset the final key is freetext.


Is there a way to override key-specs in test like it is possible for fn-specs with instrument?


see the second argument to instrument, specifically :overrides :stubs :gen


I don’t see :overrides in the doc string of instrument. I also don’t see a possibility to override key-specs.


With key-spec I mean (s/def ::a int?). I like to override ::a.


sorry, I goofed, that's not an actual config key

ghadi16:07:26 You cannot override key specs. You can only override which specs are bound to particular functions, and which generators are used for particular specs


Overriding the key spec doesn't really make sense conceptually -- you'd be changing the contract but preserving the same global name


I have a function which gets a map of values and I don’t like to generate the real values in test. So I would like to override the specs for the keys in the map. But if I think more about it, why should a supply a map to the function at all? So I can change the fn-spec to take a custom test value instead of a map which custom test values in it. That should work. Oh I also stub the function.