hi guys, I'm in a situation that we have two kind of specs:

# "correct" spec, this one is used to do validation, instrument 
and # "test" spec, this one is mainly to use in gen test. Since when doing test, sometimes I want a function to handle all kind of input instead of the "correct" one generated by "correct" spec.

@nxqd I would have a single spec but override the generator.

You want the same "correct" spec in both production code and test code -- but it's reasonable to have a generator that produces simpler data. You do not want the other way around.

Perhaps you're not explaining what you're really trying to do?

If you're explicitly doing validation inside the function, then the arguments it takes are a different spec, by definition, since the function takes a broader range of data -- it's expecting a broader range of data so that it can validate a small range of data and do something different and observable for the "invalid" data.

i.e., (if (s/valid? ::some-spec input-data) (do-good-stuff input-data) (do-something-else input-data)) -- the function is anticipating input-data that does not conform to ::some-spec and it is expected, defined, testable behavior that the function does something else -- and the function accepts, as part of its core production spec input data that is beyond just ::some-spec. Does that make sense @nxqd ?

yeah you are correct. The approach I'm doing atm is basically the same as you mentioned above. what I have in mind is to design it like this:

code-ns
(s/fdef ... :args (s/cat :args ::args))
(defn ... )

test-ns
(s/fdef ... :args (s/cat :args ::args)) ;; the only different of this ::args is the gen function as you said.
;; register this fdef instead of the one above and run tests.
;; since the real implementation will still use the "correct" spec, there is no problem regarding valid? in function.

No, what I'm saying is the function itself has one spec that is the same for test and production. It may be a different spec from what it checks (validates) inside the function.

A generator for a spec cannot generate data that fails to conform to the spec, so the generator may generate a subset of acceptable data, but not a superset.

hmm, interesting. I got your point now

Consider an API function that accepts arbitrary strings as arguments but then conforms the arguments to numeric values -- the function argument spec is basically string? and then it will have a separate spec for conforming numeric strings to numbers.

Since you want the arguments to function to be mostly numeric, you need a custom generator that mostly generates numbers and calls str on them, but sometimes generates arbitrary strings (which will fail the other spec) and cause the function to do whatever error handling you expect.

agree. this clears my mind. What is your naming convention for fdef args spec and separate spec?

(s/def :fdef/arg )
and (s/def :correct/arg ) ?

It depends on the business domain. In this case, I'd probably have a :domain/spec for the conforming spec and a :api/spec for the function argument spec.

great ! Thanks a lot. Have a nice day sir 😄

Glad to help!

Can I get some help with writing a spec? I want a vector of of alternating types, similar to a tuple spec but repeating where the types of the first and last are the same. The following is invalid but hopefully suggests what I am looking for. (s/def ::graph-path (s/tuple-ish ::node ::edge ::node ::edge ... ::node))

In think I figured it out... (s/def ::graph-path (s/cat :h ::node :r (s/* (s/cat :e ::edge :n ::node)))