Fork me on GitHub
Alex Miller (Clojure team)01:08:38

I think both are working by swapping vars, so probably, but it might get weird. try it and see.


Seems like it is when the with-redefs happens before the instrument. But I've got mixed feelings about this idea 😄


Probably better not to do that

Oliver George10:08:44

Is this a common pattern: isolate a fn by stubbing everything else and running stest/check on it.

(defn check-all []
  (let [syms (stest/instrumentable-syms)]
    (doseq [sym syms]
      (let [stub-syms (disj syms sym)]
        (stest/instrument stub-syms {:stub stub-syms})
        (stest/summarize-results (stest/check sym))

Alex Miller (Clojure team)12:08:16

First time I’ve seen it, but interesting

Oliver George01:08:35

I was thinking it would give you confidence that the inputs and outputs through the code match up. So essentially a cheap type checking substitute. The downside of that approach is that for full code coverage the generated data needs to trigger all branches of conditionals… I think that’s probably not something you can rely on.


Looks like it isn't an option, but curious if there's a way to specify an fspec for check like you can for excercise-fn


My goal is to check a fn with an fspec whose :fn is specific to a more narrow generator.

Alex Miller (Clojure team)18:08:17

you can do that with instrument first

Alex Miller (Clojure team)18:08:09

with the :replace functionality

Alex Miller (Clojure team)18:08:16

if I understand your goals that is


Looking at the docs for instrument I think :spec should do what I want, but trying the following still uses the registered fdef for files-reducer instead of the override fspec


(st/instrument `files-reducer {:spec {`files-reducer (s/fspec :args (s/cat) :ret any? :fn (fn [_] false))}})
(expound/explain-results (st/check `files-reducer))